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(57) Abstract 

A software method and tool for use in developing, selling, operating and managing timeshare properties. In the marketing and sales 
stage of managing timeshare properties, timeshare products are created by defining usage type (150) for each product and defining usage 
rights (155) associated with the usage type (150), The usage type can have a space dimension component, and/or a points based component 
A hotel inventory (1 15) is developed based on resort, room type, and room information. 
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Software Tool for Management of Timeshare Properties 



This patent application claims priority from U.S. Provisional Patent 
Application Serial Number 60/130,076 for SOFTWARE TOOL FOR 
5 TIMESHARE PROPERTY MANAGEMENT which is hereby incorporated by 
reference. 
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Field of the Invention 

The present invention relates to a software tool for use in managing 
timeshare properties, and more particularly to a property management tool that 
includes defining usage types, usage rights, products, product inventory, sales 
inventory, and resolved usage rights. 



Background of the Invention 

Timesharing generally refers to the proportional use of a piece of 
V property by a plurality of owners. The evolution of the timeshare industry 

15 appears to have begun with small groups of perhaps three or four people that 
would collectively purchase a condominium and proportionally share usage of 
the condominium. Later on, investors began purchasing condominium or 
other properties and partitioning the use of the condo into 52 one week 
segments. The partitioned use of the condo was offered for sale to people 

20 interested in regularly using a particular condo for a particular week each 
year. For example, a person could purchase a timeshare interest in the third 
week of each year at a particular condo in Aspen, Colorado. In timeshare 
parlance this is referred to as a fixed/fixed usage type, i.e., the time aspect, the 
third week, is fixed and the space aspect, the particular condo in Aspen, is 

25 fixed. Timeshare inventory management at this stage in the development of 
the timeshare industry was relatively simple to perform. Oftentimes, 
timeshare inventory management was performed with a chalkboard having a 
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grid with the 52 weeks of the year on one axis and the inventory, i.e., 
timeshare condos, on the other axis. The intersection of a particular week and 
a particular unit is a fixed/fixed product. The timeshare owner was simply 
written into the appropriate box on the grid. 
5 The early timeshare models, however, did not provide enough 

flexibility for timeshare developers. Oftentimes a perspective timeshare 
purchaser was more likely to make a purchase if it involved more flexible 
usage of a particular timeshare property, the ability to use alternative 
timeshare properties in the same resort, or perhaps the ability to use 

10 alternative timeshare properties owned by a particular timeshare manager but 
in different locations. For example, the concept of floating or flexible usage 
developed wherein a person purchased a timeshare interest in a particular type 
of unit, e.g., two bedrooms, at a particular resort, e.g.. Aspen, for a particular 
season, e.g., ski season. In this example, the usage type the person purchased, 

15 a two bedroom unit in Aspen each year during ski season, is referred to as a 
"floating" usage type. The purchaser/owner would have to call the resort and 
make a reservation for their timeshare which was based on availability. The 
person was not guaranteed a particular week or a particular unit. Undgj- tj^^ 
floating model, a person could potentially lose out on their timeshare right for 

20 a given year if they waited too late into their season to make a reservation and 
there were no longer units available. Inventory management under the 
floating model is much more complicated than for fixed products. 

After the floating and fixed usage types, permutations of the two 
developed and new usage types such as "points" emerged. A "product" as 

25 discussed in more detail below, is a function of the usage type and defines 
what a times share developer has to sell. The various different models 
discussed herein are collectively referred hereinafter as "usage types." 
Accordingly, a timeshare product is a function of the usage type. Current 
timeshare management software does not allow user-defined usage types and 

30 hence does not provide the timeshare developer with flexibility in defining 

and selling new products. Rather, the timeshare developer must conform their 



wo 00/63794 PCT/USOO/10492 

3 

range of products to the available usage types. This lack of flexibility in 
creating products significantly limits the ability of timeshare developers to 
sell their products. Accordingly, an object of the present invention is to allow 
user-defined usage types to provide timeshare developers with the utmost 
5 business flexibility. Moreover, another object of the present invention is to 
allow timeshare inventory management to take into account the custom 
products developed by the timeshare developer. 

A further object of the present invention is to handle inventory 
management for multi-site timeshares, vacation clubs and complicated 

10 organizational structures. Multi-site timeshares and vacation clubs are similar 
in that they both give participants access to more than one property. For 
example, a vacation club allows a club participant to use various properties 
with the club. Oftentimes the club properties are in different locations such as 
Florida and Las Vegas. Accordingly, the timeshare owner can go to the club's 

15 property in Florida or Las Vegas. To facilitate the vacation club concept and 
the mutli-site timeshare concept, a product has been created referred to as 
"points." Each piece of inventory that is sold, such as a unit in Florida, is 
^ggjgj^gj ^ p^jjj^g ^^1^^ Numerous factors are involved in assigning a points 
value to piece of inventory, such as season, view, size of unit and location. 

20 The various pieces of inventory in the club may have different points values. 
Accordingly, an owner of 15,000 points might be able to use a unit in Florida 
that has a points value of 7,500 two times or use a unit in Las Vegas that also 
has a points value of 5000 three times. Numerous permutations of the 
vacation club have evolved. The most common are "pure points" clubs, 

25 "inventory backed points" and hybrids of the two. In a pureipoints clubithe 
owner does not have an interest in a particular piece of property. Rathier, an 
overall points value is assigned to all inventory and points are sold that gives 
the buyer access to all inventory in the club. In an inventory backed points 
club the owner has an interest in a certain unit that is assigned a points value 

30 that allows the owner to use other properties in the club. Accordingly another 
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object of the present invention is to provide inventory management for the 
various current and yet to be defined points based products. 

In the timeshare industry, complicated organizational structures arise 
when a single timeshare developer obtains financial support from different 
5 sources to develop different properties. Oftentimes, a timeshare developer 
starts a company to develop and manage a timeshare property and enlists 
investors for the property development. For the next timeshare property that 
the developer v/ishes to develop some or all of the original investors may be 
uninterested in the second development. Accordingly, a second company is 

10 formed to develop and manage the second timeshare property. The timeshare 
developer than has the task of managing the various properties, marketing the 
various properties, and directing the revenue from the various properties 
which may be organized differently from one another. Accordingly, a further 
object of the present invention is to provide inventory management for 

15 timeshare owners with complicated organizational structures. 

Another problem with time share property management relates to 
determining the rights an owner has when the owner calls in to make a 
i-gggi-y^liQU Qm^gjji gygi^jjjg j^^iy ^ jj^^^j^ agent to determine what rights 
are available to a particular timeshare owner at a particular time. For 

20 example, a timeshare owner may not have the right to reserve a particular 
room at a certain time of the year. If that person calls to reserve a particular 
room at that time of the year, current systems do not automatically notify the 
agent of the person's rights. 

A further object of the inventory management capabilities of the 

25 present invention is to minimize or eliminate the number of room switches a 
particular timeshare owner would have to endure during a given stay - room 
switching is highly undesirable for timeshare owners and oftentimes is 
contractually prohibited. 

It is against this background that the software tool for managing 

30 timeshare properties of the present invention was developed. A description of 
the invention follows. 



wo 00/(i3794 PCT/USOO/10492 

5 

Summary of the Invention 

The present invention relates to a computer based method used in 
timeshare development and management for defining a timeshare product. 
The method includes defining a usage type based on the arrangement of a set 
5 of usage type variables and defining a usage right associated with the usage 
type. The usage right is based on the arrangement of a set of usage right 
variables. The characteristics of the product are a function of the usage type 
and the associated usage right. 

The usage type may include a space dimension component and a time 

10 dimension component The usage type may include a point-based usage type. 
The usage type may include a space dimension component, a time dimension 
component, and a points-based component. The set of usage type variables 
may include a sales time unit variable, a sales time unit count variable, a sales 
increment variable, a sales points variable, a pricing unit allocation variable, a 

15 pricing time allocation variable, a contract unit allocation variable, and a 
contract time allocation variable. 

The space dimension component may include one of a fixed space 
dimension component and a floating space dimension component. The time 
dimension component may include one of a fixed time dimension component, 

20 a floating time dimension component, and a fractional time dimension 

component. The usage type may include a whole ownership usage type and a 
pure points usage type. 

The method may further include the operation of defining a time unit. 
The time unit may be a function of a day. The time unit may include a 

25 baseline factor, the baseline factor defining the time unit as an even multiple 
of a day. The time unit may include a baseline factor, the baseline factor 
segmenting the time unit into discrete portions of a day. The operation of 
defining a usage right may include the operations of defining a reservation 
start date and a reservation end date for each usage right, the reservation start 

30 date and end date together defining a reservation window in which a 
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reservation can be made for the product being defined, the reservation start 
date defining the first day of the reservation windov^ that a reservation can be 
made and the reservation end date defining the last day of the reservation 
window that a reservation can be made. 
5 The operation of defining a usage right may include the operations of 

defining a usage start date and a usage end date for each usage right, the usage 
start date and the usage end date together defining a usage window in which 
the product being defined may be used, the usage start date defining the first 
day of the usage window that the product may be used and the usage end date 

10 defining the last day of the usage window that the product may be used. 
The operation of defining a usage right further may include the 
operation of defining an accommodation for each usage right, wherein the 
accommodation includes unit, unit type and resort. The operation of defining 
a usage right may include the operation of defining a Boolean operator, 

15 wherein the Boolean operator determines the interaction between each usage 
right defined. The operation of defining a usage right may include the 
operation of defining a policy associated to the usage right wherein the 

The method may further include adding a membership to the product 
20 wherein the membership includes additional usage rights. The method may 
further include defining a points package for the product, the points package 
including a points increment representing the number of points that the points 
package represents. 

The present invention also relates to a computer based method used in 
25 timeshare development and management for developing and managing 

timeshare inventory. The method includes defining a timeshare product, each 
product having space and time characteristics, and defining a sales inventory. 
The sales inventory includes a set of sales inventory entities available for 
association with the timeshare product, the sales inventory entities defining a 
30 plurality of particular spaces. The method also includes linking the timeshare 
product with the sales inventory to create a product inventory. The product 
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inventory includes a set of product inventory entities available for sale as a 
timeshare interest, the product inventory entities including particular rights to 
space and time that can be used by a purchaser of the timeshare interest. 

The operation of defining a sales inventory may include the operation 
5 of defining a resort, defining a unit type, and defining a unit. The method 
may further include defining a hotel inventory and mapping the hotel 
inventory to the sales inventory. The operation of defining a hotel inventory 
may include the operations of defining a resort, defining a cluster, defining a 
room type, and defining a room. The operation of linking a product to a sales 
10 inventory may include selecting the product, defining a search criteria that 
describes a particular entity within the set of sales inventory entities, 
searching the sales inventory according to the search criteria, and displaying 
any matches between the search criteria and the sales inventory found in the 
search. 

15 The product may include a non pure points product. The operation of 

linking the product to the sales inventory for the non pure points product may 
include defining a product calendar, defining a maintenance increment, 
jj^llj^jj^j^^ ^ pj^j^j^g ^^^^jl^^^^^ initializing a points attribute, initializing an 
inventory dates attribute, and initializing a business entities attribute. The 

20 product may include a pure points product. The operation of linking the 

product to the sales inventory for the pure points product may include defining 
a price for the pure points product and initializing a business entities attribute. 

The present invention also relates to a computer based method used in 
timeshare development and management for developing and managing 

25 timeshare inventory. The method includes selling a timeshare interest, the 
timeshare interest including a page iight defining how the timeshare interest 
may be used. The method also includes resolving the usage right to generate a 
resolved usage right wherein the resolved usage right defines how the 
timeshare interest may be used at a particular time. 

30 The present invention also relates to a computer based method used in 

timeshare development and management for developing and managing 
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timeshare inventory. The method includes defining a timeshare product 
including a usage right, defining a sales inventory, and defining a hotel 
inventory. The method also includes linking the timeshare product to the 
sales inventory to define a product inventory including a set of product 
5 inventory entities available for sale, each of the product inventory entities 
including the usage right. The method also includes selling a product 
inventory entity, resolving the usage right to generate a resolved usage right, 
and allowing a reservation to be made for the product inventory entity based 
on the resolved usage right. 

10 The operation of selling a product inventory entity may further include 

selecting a product inventory entity, defining a search criteria for the product 
inventory entity including a space dimension search criteria and a time 
dimension search criteria, searching for the product inventory entity matching 
the search criteria, and selecting a product inventory entity from a set of 

15 product inventory entities that match the search criteria. The operation of 
defining a sales inventory may include defining a resort, defining a unit type 
and defining a unit. The operation of defining a hotel inventory may include 
defining a resort, defining a room type, and defining a room. The operation of 
defining a product may include defining a time unit and defining a usage type 

20 using the time unit, wherein the usage right is associated to the usage type. 

The present invention also relates to a software system for timeshare 
development and management. The system includes a usage type definition 
module including a set of definable usage type variable fields, a usage right 
definition module including a set of definable usage right variable fields, and 

25 a timeshare product definition module including a set of definable timeshare 
product variable fields. The usage type module, the usage right module, and 
the timeshare product definition module can be utilized together to define a 
timeshare product. The system may further include a time unit definition 
module. 

30 The present invention also relates to a computer program product 

embodied in a tangible media. The product includes a set of program code to 
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implement a usage type definition module, wherein the usage type definition 
module includes a set of definable usage type variable fields. The product 
also includes a set of program code to implement a usage right definition 
module, wherein the usage right definition module includes a set of definable 
5 usage right variable fields. The product further includes a set of program code 
to implement a timeshare product definition module, wherein the product 
definition module includes a set of definable timeshare product variable fields. 
The usage type module, the usage right module, and the timeshare product 
definition module can be utilized together to define a timeshare product. 
10 The tangible media may include a magnetic disk. The tangible media 

may include an optical disk. The tangible media may include a propagating 
signal. 

The present invention also relates to a system used in timeshare 
development and management for developing and managing timeshare 

15 inventory. The system includes a timeshare product definition module 

including a set of time unit definition fields, a set of usage type definition 
fields, and a set of usage right definition fields, the product definition module 
operative to create a timeshare product. The system also includes a sales 
inventory definition module including a set of resort definition fields, a set of 

20 unit type definition fields, and a set of unit definition fields. The sales 

inventory module is operative to create a sales inventory that includes a set of 
sales inventory entities. The system further includes a product inventory 
definition module including a product field, a set of sales inventory entity 
fields, and a linking module. The linking module is operative to link the 

25 timeshare product with the sales inventory entity to create a product inventory 
that includes a set of product inventory entities that are available for sale as a 
timeshare interest. 

The foregoing and other features, utilities and advantages of the 
invention will be apparent from the following more particular description of a 

30 preferred embodiment of the invention as illustrated in the accompanying 
drawings. 
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Brief Description of the Drawings 

Figure 1 is a high level block diagram illustrating the exemplary 
interactions between an exemplary hotel inventory, an exemplary sales 
inventory, an exemplary set of product configurations, an exemplary product 
5 inventory, and an exemplary hotel inventory control of the present invention; 

Figure 2 is a flowchart illustrating high level operations of the present 
invention; 

Figure 3 is a flowchart illustrating high level operations of the product 
definition operation of the present invention; 
10 Figure 4 is a flowchart illustrating time unit definition operations; 

Figure 5 is a flowchart illustrating resort season calendar definition 
operations; 

Figure 6 is a flowchart illustrating usage type definition operations; 
Figure 6a is a table illustrating exemplary usage types and associated 
15 attributes utilized in the configuration of the usage types; 

Figure 6b is a table illustrating exemplary fractional products; 
Figure 7 is a flowchart illustrating usage rights definition operations; 
Figure 8 is a flowchart illustrating timeshare product definition 
operations; 

20 Figure 9 is a flowchart illustrating membership definition operations; 

Figure 10 is a block diagram illustrating an exemplary representative 
configuration of hotel inventory; 

Figure 11 is a block diagram illustrating an exemplary representative 
configuration of sales inventory; 
25 Figure 12 is a flowchart illustrating the high level operations of 

defining hotel inventory and defining sales inventory; 

Figure 13 is a flowchart illustrating the fields and operations involved 
in defining a resort; 

Figure 14 is a flowchart illustrating the fields and operations involved 
30 in defining a room type; 
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Figure 15 is a flowchart illustrating the fields and operations involved 
in defining a room; 

Figure 16 is a flowchart illustrating the fields and operations involved 
in defining a unit type; 
5 Figure 17 is a flowchart illustrating the fields and operations involved 

in defining a unit; 

Figure 18 is a flowchart illustrating product to sales inventory 
association operations; 

Figure 19 is a flowchart illustrating non pure points product to sales 
10 inventory association operations; 

Figure 20 is a flowchart illustrating pure points product to sales 
inventory association operations; 

Figure 21 is a flowchart illustrating contract inventory selection 
operations; 

15 Figure 21a is an exemplary window illustrating the inventory selection 

fields; 

Figure 22 is an exemplary window illustrating the main menu screen of 
the Tool; 

Figure 22a is an exemplary tool bar of the inventory management 
20 navigation module; 

Figure 22b is an exemplary drop down menu of the inventory 
management portion of the inventory management navigation module; 

Figure 22c is an exemplary window illustrating the hotel inventory 
window; 

25 Figure 22d is an exemplary window illustrating the sales inventory 

window; 

Figure 22e is an exemplary window illustrating the sales product 
window; 

Figure 22f is an exemplary window illustrating the product drop down 
30 menu of the product portion of the inventory management navigation module; 
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Figure 22g is an exemplary window illustrating the inventory drop 
down menu of the inventory management navigation module; 

Figure 23 is an a flowchart illustrating the usage right resolution 
operations; 

5 Figure 23a is a table illustrating the resolved usage right logical 

relationships between sales time allocation attributes and contract time 
allocation attributes; 

Figure 24 is a table illustrating sustained availability; 

Figure 25 is a flowchart illustrating overbooking operations; 
10 Figures 25a - 25e are tables illustrating overbooking; 

Figure 26 is an exemplary window illustrating a set of blocking fields; 

Figure 27 is a flowchart illustrating member call processing operations; 

Figure 27a is a flowchart illustrating fixed product reservation 
operations; 

15 Figure 27b and 27c are flowcharts illustrating floating product 

reservation operations; and 

Figures 27d and 27e are flowcharts illustrating point product 
reservation operations. 

Detailed Description of the Preferred Embodiment 

20 The software tool for managing timeshare properties (hereinafter 

"Tool") of the present invention is a comprehensive system and method that 
allows a timeshare developer or manager (hereinafter "user") to create and 
manage three distinct but interrelated types of inventory - product inventory, 
sales inventory, and hotel inventory. Figure 1 is an exemplary block diagram 

25 illustrating product inventory 105, sales inventory 110, hotel inventory 115, 
hotel inventory control 120 and their interrelationships. Figure 1 is referred to 
throughout this document for illustrative and exemplary purposes. 

Product inventory 105 comprises what may be sold as a timeshare. For 
example, a particular piece of product inventory, /.e., a widget 125, may be 
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the right to use a two bedroom unit 130 at the Sunbay Resortl35 between 
January 1 and January 7 of each year. Sales inventory 1 10 comprises the 
logical space that may be sold as a part of the product inventory 105. For 
example, the two bedroom unit 130 at the Sunbay Resort 135 is a piece of 
5 sales inventory. Finally, hotel inventory 1 1 5 comprises the space that may 
actually be used when a reservation is made. In the examples provided above, 
a piece of hotel inventory may be Room 101 (140) (a particular two bedroom 
unit) at the Sunbay Resort 135. 

Product Inventory 105 (hereinafter "PI"), sales inventory 110 

10 (hereinafter "SI") and hotel inventory 115 (hereinafter "HI") are both created 
and managed by the Tool. The creation of PI 105 involves the definition of 
products 145. A product 145, as mentioned above, is the set of parameters 
that define the timeshare rights. A product includes usage types 150 and 
usage rights 155. Exemplary usage types 150 include the type of unit that a 

15 timeshare owner may use (e.g., two bedroom) and the particular time of the 
year that the unit may be used (e.g., Jan. 1 - Jan. 7). An exemplary usage 
right 155 is the time when the owner may make a reservation for the timeshare 
(e.g., 6 months before Jan. 1). The creation of PI 105 also involves the 
association of products to SI 160. 

20 The creation of SI 110 involves, essentially, the definition of the details 

of a particular property into pieces that may then be associated to a product 
and together sold. For example, the SI for the Sunbay Resort 135 may include 
two types of units 162, a 3 bedroom unit type 164 and a two bedroom unit 
type 166. There may be one three bedroom unit, unit 105 (168); and four two 

25 bedroom units, unit 101 (170), unit 102 (172), unit 103 (174), and unit 104 
(176). The SI is defined as resort (Sunbay), unit type (three bedroom, two 
bedroom) and unit (3BR) (105), Unit (2BR) (101, 102, 103, and 104). 

Accordingly, in a simplistic example of the association of a product to 
SI, if the product is a fixed 2 bedroom at the Sunbay Resort for Jan. 1 to Jan. 7 

30 (hereinafter "weekl"), then four two bedroom/weekl widgets 178, i.e., pieces 
of product inventory, are created that may each be sold. The timeshare owner 
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would have the right to use one of the two bedroom units during weekl . In a 
second simplistic example of the association of a product to SI, if the product 
is Unit 101 at the Sunbay Resort during weekl, then one Unit 101 /weekl 
widget 180 is created that may be sold. The timeshare owner has the right to 
5 use Unit 101 at the Sunbay Resort during weekl. 

In addition to providing for the creation and management of each one 
of the above exemplary widget types, the tool provides for the creation and 
manage of a plurality of widgets at one time. Referring to the example above, 
if the four two-bedroom/week 1 widgets 178 and the unit 101/weekl 180 

10 widget are both created for the Sunbay Resort and the unit 101/weekl widget 
is purchased, then the PI automatically removes the unit 101 from availability 
for the two-bedroom/week I widgets 178. Accordingly, there would only be 
three two-bedroom/week 1 widgets available for sale. 

The creation of HI 115 involves, essentially, the set-up of the details of 

15 a particular property into pieces that may then be used by both timeshare 
owners and transient guests. Transient guests refers to anyone, other than a 
timeshare owner, iKat stays in a room in a hotel, e.g.^ business travelers. For 
example, still referring to the Sunbay Resort 135, the HI 1 15 for the Sunbay 
Resort may be defined as three clusters 182 (three bedroom, two bedroom and 

20 studio), four room types 184 and associated rooms 186 (three bedroom ocean 
view (105, 106), two bedroom ocean view (101, 103 and 105A), two bedroom 
golf view (102, 104, 109), and studio (105B, 108, 110)). Note, the SI is a 
subset of the HI because only a portion of the Sunbay Resort is meant for sale 
as timeshares. 

25 The actual ability of a timeshare owner to use their timeshare requires 

the generation of resolved usage rights 188. Resolved usage rights 188 
involves, generally, the reduction from a plurality of usage rights 155 
associated with a particular widget into a set of resolved usage rights that 
define what rights the timeshare owner has at a particular time. Usage rights 

30 are defined during the product definition operations. For example, two usage 
rights for a particular widget may be: "Right 1" the right to make a reservation 
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for Unit 101 at the Sunbay Resort during Weekl, if the reservation is made 
more than 365 days before Weekl, and "Right 2" the right to make a 
reservation for a two bedroom unit at the Sunbay Resort during Weekl, if the 
reservation is made between 365 days before Weekl and the first day of 
5 Weekl . Accordingly, the resolved usage right at 400 days before Weekl is 
usage Right 1, and the timeshare owner may therefore reserve unit 101 for 
weekL Hotel inventory control 120 accounts for this resolution and allocates 
the appropriate space 190 - unit 101 during week 1 - to the timeshare owner. 
The following discussion provides a more detailed description of the 

10 Tool. The operations associated with Figures 2 - X, as discussed below, are 
presented in a particular order for ease of discussion and understanding. The 
order of the operations associated with the various flowcharts below, however, 
is not a requirement of the present invention. Moreover, many of the 
operations discussed in the following flowcharts include operations that may 

15 be executed discretely. The user input and manipulation mechanism for the 
Tool is preferably implemented using graphical user interfaces (hereinafter 
"GUI") as provided by the Windows™ operating system. Any suitable 
interface including Qomju^uj^ jj-j^^j^ -j^l^^j.^^^^^ provided by dqS, and GUIs 
as provided by the Apple™ operating system, however, may be utilized. The 

20 tool preferably runs on a Windows NT™ server or Unix ™ server and utilizes 
an Oracle™ database. Preferably, the software code for the Tool is 
implemented using Power Builder™ by Sybase™. 

Figure 2 is a flowchart illustrating the exemplary hierarchical or main 
operations involved in the use of the Tool. In main operation 205, the user 

25 defines a set of products. A product is the set of parameters that define the 
timeshare rights that eventually can be sold. Product definition includes 
defining usage types and usage rights. Usage types generally define what may 
be used and when it may be used. Referring to Figure 1, an exemplary usage 
type 150 is "fixed/fixed" which is a fixed unit, e.g., unit 101, for a fixed time, 

30 e.^., weekl . Usage rights generally define how the usage type may be used. 
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Two exemplary usage rights 155 include the right to reserve a specific unit or 
the right to reserve a type of unit. 

In main operation 210, the user defines a set of SI and a set HI. The SI 
represents the logical inventory at a resort, e,g,, a particular unit at a 
5 particular resort, that may be sold as part of a timeshare. All of the particulars 
of a resort that will be sold as a timeshare are defined in the SI. Referring to 
Figure 1, the SI 1 10 definition includes the resort 135, the unit types 162 and 
the particular units 168-170. The HI represents the usable inventory at a 
resort, e.g., room 101 (140), that is used by both timeshare owners and 

10 transients. "Transients" refers to non-timeshare owners, er.g., hotel guests. 
The HI definition includes the resort 135 and associated resort entities 
including clusters 184, buildings, floors, room types 184 and rooms 186 along 
with details about them that define the characteristics of the resort entities that 
may be used by timeshare owners and transients. 

15 In main operation 215, the products are associated to the SI to create 

product inventory 105. Each discrete component or "widget" 125 of the 
product inventory 105 is available for sale as a timeshare. The term widget is 
used because the Tool may be used to create and manage timeshare interests in 
items other than units. 

20 In main operation 220, a widget is sold. As part of the selling 

operation, the buyer goes through a contract inventory selection operation that 
includes, selecting a particular widget to purchase, optionally becoming a 
member which provides enhanced rights in the widget, optionally having a 
points value associated with the widget which provides alternative uses for the 

25 widget. 

After the sale of a widget, in operation 225, the Tool generates resolved 
usage rights 188. This operation is done periodically and provides the 
mechanism by which the owner may use the widget. During product 
definition, usage rights and policies are defined for each product. The usage 
30 rights and policies define how a product may be used by the timeshare owner. 
Oftentimes, usage rights and policies are a function of time. For example, a 
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usage right associated with a product may provide rights to a particular unit at 
time X (such as between 6 and 12 months in advance) while another usage 
right associated with the product may only provide rights to a particular unit 
type at time Y (such as between 3 and 6 months in advance). These two usage 
5 rights are resolved in operation 225 to determine how, at a particular time, the 
widget may be used. For example, at time X the timeshare owner may reserve 
the particular unit whereas at time Y the owner may only reserve a particular 
unit type. 

In main operation 230 a reservation is made at a resort. The 

10 reservation operation utilizes HI 1 15, a member servicing module 235, hotel 
inventory control 240, resolved usage rights 225 and points rates information 
245. In main 250, the Tool updates inventory availability based on the 
reservation made in operation 230. 

After the sale of a widget in main operation 220, the Tool may also be 

15 used to predict future resort availability in main operation 255 and set aside 
blocks in main operation 260. Prediction of future resort availability and 
blocking is discussed in more detail below. This can include blocking out 
certain weeks from general availability to persons seeking to stay at a property 
who are not timeshare owners. 

20 The operations discussed in conjunction with Figure 1 are discussed in 

detail below. The present invention is not limited to managing timeshare 
properties. Rather, the present invention is robust enough to define products, 
sales inventory, and sell widgets that are not property based and then manage 
their use. For example, a timeshare product may be defined to create an 

25 interest in sunset cruises on a particular yacht. Or, for example, a timeshare 
product may be defined to create an interest in golf course tee times or 
racquetball court times. For ease of understanding, however, the description 
herein will primarily use property based examples to describe the present 
invention. 

30 
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PRODUCT DEFINITION 
Figure 3 is a flowchart illustrating an exemplary hierarchical or main 
operations by which a timeshare product is defined. In main operation 300, 
the product definition operations begin. Product definition allows a user to 
5 define a customized set of timeshare products. Generally, defining a 

timeshare product is a preliminary operation in creating a widget which is 
typically a customized interest in a given piece of property, e.g., unit 101 
(140), typically located at a resort, e.g., Sunbay (135), meant for reoccurring 
use by the eventual timeshare owner, e.g., weekl of each year. As described 

10 in further detail below with respect to Figures 18-20, SI is associated with a 
product to create PI, a set of timeshare widgets, that may be sold. 

In main operation 310, the user may define a customized time unit. 
The majority of the timeshare industry currently operates on a week-centric 
schedule, meaning that each timeshare property is typically divided into 52 

15 one week blocks or "increments" wherein each increment may be owned by a 
timeshare owner. The dynamic nature of the timeshare industry, however, 
demands that any inventory management tool be able to support a plurality of 
customized time units. A.ccordingly, the Tool includes operations that {j^^i^^ 
a customized time unit. 

20 The system predefines a "day" and a "year" (i.e., 365 days) as the base 

time units for further defining a customized time unit. A customized time unit 
that is greater than a day is composed of multiple predefined days. For 
example, a customized time unit named "month" may be defined as 28 days. 
A customized time unit that is less than a day may be partitioned in terms of a 

25 standard hour, minute or second. Each customized time unit that is defined is 
saved and is available for later use in defining products. 

In main operation 320, the user defines a resort season calendar. The 
resort season calendar is a compilation of time units. Generally, the resort 
season calendar breaks down a particular resort's use year into a set of seasons 

30 that are composed of time units. The resort season calendar is used by many 
of the other modules discussed below. In addition, for every time unit defined 
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a corresponding resort season calendar must also be defined. The resort 
season calendar for a particular time unit must be created prior to selling a 
widget that includes the time unit. 

In main operation 330, the user may define a customized usage type. 
The usage type is a template that is used to determine how a given product's 
inventory is controlled, priced and sold. Generally, a usage type relates to 
both the space and time dimension for the ultimate product. The space 
dimension refers to the physical space of the item designed to be associated 
with the product, e.g.. a condominium unit or a seat on the yacht. The time 
dimension refers to the time the product is meant to be used, e.g., "weekl" the 
first week of each year. Preferably, the Tool includes fixed, floating and 
points usage types for both the space dimension and the time dimension. 

A fixed usage type for the space dimension preferably refers to a fixed 
unit, e.g., unit 101. A fixed usage type for the time dimension preferably 
1 5 refers to a fixed time, e.g.. the first week of High Season. Note, High Season 
is an exemplary season that is defined in the resort season calendar, discussed 
herein in conjunction with main operation 320, that represents a plurality of 
associated time units generally encompassing a particular season, such as ski 
season at a ski resort. A floating usage type for the space dimension 
preferably refers to a type of unit, e.g., a two bedroom unit. A floating usage 
type for the time dimension preferably refers to a particular season, e.g., all of 
High Season. A points usage type provides space dimension and time 
dimension flexibility to the product. With a pure points usage type the 
timeshare owner may reserve any unit at any resort during any time with an 
25 equal or lesser point value as long as the unit, resort and unit are included in 
the timeshare. As discussed in more detail below, points may be included 
with any product to give increased flexibility to the timeshare product. 

In main operation 340, the user defines usage rights and policies for a 
given product which is associated with a usage type. Each product will have 
30 at least one associated usage right and may have more. Additionally, each 

product may have multiple associated usage rights and the eventual buyer may 



20 



wo 00/63794 PCT/USOO/10492 

20 

select to purchase a product having some subset of the available rights. An 
exemplary usage right defines what type of reservation may be made as a 
function of the time when the timeshare owner attempts to make the 
reservation. For example: Right 1 provides that if a reservation is made more 
5 than one year from the start of High Season, then unit 101 / weekl of High 
Season is guaranteed; and. Right 2 provides that if a reservation is made less 
than one year from the start of High Season, then a two bedroom unit during 
High Season is guaranteed. Note, the exemplary Right 1 and Right 2 would 
not apply to a pure fixed/fixed product wherein a particular unit at a particular 

10 time is purchased. An exemplary policy defines what alternative uses may be 
made of a particular usage right. For example, the policy may provide that a 
timeshare interest in unit 101 during weekl may be released into a rental 
program. The rental program generally that coordinates the rental of the unit, 
and the timeshare owner is provided with a percentage of the rental proceeds 

i 5 instead of using the unit that year. 

In main operation 350, the time unit defined in main operation 310 and 
the usage type defined in main operation 330, along with associated usage 
jrjgji^g jjgf^jjgjj main Qpei-^tion 340, are ^itilized to define a particular 
timeshare product. A product is a function of a usage type and a time unit and 

20 defines what is eventually associated with SI to create widgets that are sold. 
In main operation 360, add-on memberships are supported. 
Membership is an optional or mandatory enhancement sold with a widget that 
typically expands the usage rights associated with a particular product. 
Time Unit 

25 Figure 4 is a flowchart illustrating the exemplary operations associated 

with defining a time unit. In operation 402, the user determines whether a 
new time unit will be added to the Tool and hence made available to define a 
usage type. If the user chooses to add a time unit, in operation 404, the user 
selects whether the new time unit is greater or less than a "day." Recall, that 

30 each defined time unit is based on a predefined "day" and "year." If the user 
chooses to define a time unit that is less than a day operation 406 follows. 
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In operation 406, the user inputs a name for the time unit. The name 
selected will then be used to identify the defined time unit throughout the 
Tool. In operation 408, the user defines a baseline factor. The baseline factor 
for time units less than a day defines the number of subdivisions in the day 
that the time unit equals. For example, if the baseline factor selected is 4, a 
day is subdivided into four, six hour blocks of time. Accordingly, the time 
unit is six hours long. In operation 410, the user names the subdivisions. 
Referring to the previous example, four subdivision names would be required, 
e,g„ "Subl," "Sub2," "Sub3," and "Sub 4." In operations 412 and 414, the 
user defines the start time and end time for each subdivision. For example, 
the start time and end time for Subl may be Midnight and 6 a.m. If the user is 
satisfied with the time unit defined, the user saves the time unit in operation 
416. In operation 418, the user may activate the newly defined time unit and 
hence make it available for usage type definition and resort season calendar 
15 definition as discussed in more detail below. The newly defined time unit 
may alternatively, however, be activated at a later time. 

If, in operation 404, the user selects to define a new time unit that is 
gj^gater than a day, then operation 424 follows. In operation 424, the user 
inputs a name for the new time unit. The name selected will then be used to 
20 identify the defined time unit throughout the Tool. In operation 426, the user 
defines a baseline factor for the new time unit. The baseline factor, for time 
units greater than a day, defines the number of days to assign to the time unit. 
For example, a newly defined time unit named ''month" with a baseline factor 
of 28 is composed of 28 days. Preferably, the Tool already includes a "week" 
25 time unit that is defined with a baseline factor of seven. If the user is satisfied 
with the time unit defined, the user saves the new time unit in operation 428. 
In operation 430, the user may activate the newly defined time unit and hence 
make it available for usage type definition and resort season calendar 
definition as described below. The newly defined time unit may alternatively, 
30 however, be activated at a later time. 
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If, at operation 402, the user had not selected to add a new time unit, 
the user may choose to delete an existing time unit in operation 434, activate 
an existing time unit in operation 426, or inactivate an existing time unit in 
operation 440. Deleting a time unit in operation 435 will remove the deleted 
5 time unit from the Tool. A previously defined time unit may be activated in 
operation 438 and hence made available for usage type definition and resort 
season calendar definition, A previously activated time unit may be 
inactivated in operation 442 and hence made unavailable for usage type 
definition and resort season calendar definition. 

10 Preferably, the time unit definition operations are implemented in a 

window, not shown herein, and preferably the workflow of the time unit 
definition window is left to right. The time unit definition window and 
associated datawindow fields, i.e., operations 400 - 442, however, do not 
enforce the workflow. Accordingly, the operations 400 - 442 may be 

15 performed in any order the user of the tool desires. 
Resort Season Calendar 

The resort season calendar structures the layout of a use year within a 
resort, ^jenerally, a resort s use year is the ^jj^'^j^^ y ^^•j* jnj^j-^^g-y^ji. ^^y^^^ 
resorts may only be open for particular times of the year, e.^., a ski resort may 

20 only be open during ski season. A resort's use year is decomposed into 

seasons which are a set of increments of time units. An increment is a single 
representation of the time unit defined by the user. For Example, a time unit 
of 7 days, le., a "week" time unit as discussed above in conjunction with 
Figure 4, is represented by 52 increments. The increments are grouped 

25 together in seasons. Every increment must be assigned to a season. Once 
completely defined, the resort season calendar serves as the default season 
calendar for the specified time unit for the specified resort. 

Figure 5 is a flowchart illustrating the exemplary operations associated 
with defining a resort season calendar. Defining the resort season calendar 

30 includes preliminary resort season calendar main operation 500a, increment 
one start date main operation 500b, seasons main operation 500c and swap 
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increment main operation 500d. The preliminary resort season calendar main 
operation 500a includes selecting the resort and selecting a time unit. In 
operation 502, the resort that the calendar is being defined for is selected from 
a set of previously defined resorts. In operation 504, the time unit that the 
calendar is being defined for is selected from a set of previously defined time 
units. 

In main operation 500b, the start dates for the first increment are 
defined. These are known as increment one start dates (hereinafter "lOSD") 
The lOSD definition determines the starting point from which all calendars of 
the selected time unit in the specified resort will begin. The lOSD is the first 
day of the first time increment in the use year for the specified time unit. The 
check-in day for each increment of a week-based product is the same day. 
This allows the user to set up a distinct calendar for each check-in day. For 
non-week based time units, e.g.. 4 days, the check-in days are a function of 
15 the lOSD. 

In operation 506, the user selects the year that the lOSD is being 
specified for. In operation 508, the user selects the start date of a "week" 
based time unit's increment with a Sunday check-in, i.e, the lOSD with a 
Sunday check-in. In operation 5 10, the user selects the lOSD with a Monday 

20 check-in. In operation 5 12, the user selects the lOSD with a Tuesday check- 
in. In operation 514, the user selects the lOSD with a Wednesday check-in. 
In operation 516, the user selects the lOSD with a Thursday check-in. In 
operation 5 1 8, the user selects the lOSD with a Friday check-in. In operation 
520, the user selects the lOSD with Saturday check-in. And, in operation 522, 

25 the user selects the Start Date of the first day in the non-week based time 
unit's increment One. Based on the lOSD the start day for any increment of 
the time unit or the start of any season may be derived from the following 
formula: IOSD+((week#-l)*time unit). 

In main operation 500c. the seasons for the resort season calendar are 

30 defined. The seasons operations allow the user to associate each time 

increment for the time unit's use year to an organization's defined season. An 
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"organization" represents a high level entity such as Marriot™ or Hyatt™ that 
has a plurality of resorts. The organization defines all possible seasons and 
the resort season calendar includes these organization defined seasons for 
selection. The season definition results in groupings of time increments. For 
5 example, the first 13 "week" increments may be grouped together to create a 
"High Season." High season may equate, for example, to what is typically 
referred to as "ski season" at a ski resort. 

In operation 524, the user defines a code for the season. The code 
allows other modules to access the season definition. For example, the code 

10 may be "highseason." In operation 526, the name for the season is selected. 
For example, referring to the example above the season may be named "High 
Season." In operation 528, the color (for display purposes) for the season is 
selected. The resort season calendar will display all dates encompassed by the 
"High Season" with the same color. And, in operation 530, the increments 

15 that the season represents are defined. Referring again to the example above, 
increments 1-13 of the "week" time unit may utilized to populate the High 
Season. 

In main operation 500d, the user dgfin^g "g^^p increments." When a 
widget is sold that includes an increment of a time unit with a guarantee that a 

20 specific day, e,g,, Easter Sunday, will always be included with the widget, 
then an adjacent increment may need to be swapped with the original 
increment so as to ensure that Easter Sunday is always included with the 
widget. The adjacent increment is the "swap" increment. 

In operation 532, the user selects the year for the swap increment 

25 operations. The year dictates what potential values are presented for the 

subsequent swap increment operations. In operation 534, the user selects the 
time increment from the specified year for the swap. In operation 536, the 
user is presented with the use year associated with the specified time 
increment. In operations 538 and 540, the user is presented with the start date 

30 and the end date for the specified time increment. In order to swap increments 
the user is presented with all of the available time increments for the year in 
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two side-by-side lists. The user selects the increments that are two be 
swapped from the two lists and executes the swap operation preferably by 
hitting a swap button. The two increments are then swapped. 

Preferably, the resort season calendar definition operations are 
5 implemented in a window, not shown herein, and preferably the workflow of 
the resort season calendar definition operations is left to right. The timeshare 
product definition window and associated datawindow fields, i.e., operations 
500 - 590, however, do not enforce the workflow. Accordingly, the operations 
500 - 590 may be performed in any order the user of the tool desires. 

10 Usage Type Definition 

Figure 6 is a flowchart illustrating the exemplary operations associated 
with defining a usage type. A usage type defines how PI is controlled, priced, 
and sold. PI, as discussed herein, comprises a set of widgets that may be sold 
as tiraeshares. Usage type definition includes main operation 600a wherein 

15 sales attributes are defined, main operation 600b wherein pricing attributes are 
defined and main operation 600c wherein contract attributes are defined. The 
sales attributes determine how PI is controlled, the pricing attributes 
determine how PI is priced and the contract attributes determine how PI is 
sold. 

20 Figure 6a is a table illustrating eight exemplary usage types and their 

associated sales attributes 620, pricing attributes 622 and contract attributes 
624. The exemplary usage types illustrated in Figure 6a include a space 
dimension component and a time dimension component, e.g., "fixed/fixed" 
626 representing a fixed unit (space dimension) and fixed time (time 

25 dimension). For timeshare interests in property, the space dimension 

represent the actual space, e.g., the unit, that is associated with the usage type 
and the time dimension represents the time in which the associated space may 
be used. The space dimension, however, may represent interests in items 
beside property such as use of a racquetball court. Preferably, the usage types 

30 described in Figure 6a are predefined in the Tool and available to the user of 
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the Tool in a pulldown window when the user initially begins the usage type 
definition operations. 

Still referring to Figure 6a, a fixed unit (space dimension) / fixed week 
(time dimension) usage type 626 is used to create a widget that includes an 
5 interest in a particular unit at a particular time, e.g., unit 101 during weekl . A 
fixed unit / floating week usage type 628 is used to create a widget that 
includes an interest in a particular unit during a particular season, e.g.^ unit 
101 during High Season. The High Season is defined in the Tool, as discussed 
above in regard to the resort season calendar, and may, for example, represent 
10 ski season. 

A fixed unit / fraction usage type 630 is used to create a widget that 
includes an interest in a particular unit for an amount of time that includes a 
plurality of increments of the selected time unit. Figure 6b provides an 
example of products using usage types with a fractional time dimension. The 

15 fractional usage types illustrated in Figure 6b are based on the "week" time 
unit provided for example above. The fractional usage types include both 
fixed and floating time dimensions. Tiie fractional time dimension for 
Fraction 1 (632) includes weeks 1-6 (634), jpQuj-^g^j^g ^^j-jj^g j^^gj^ g^^^Qi^ and 
three weeks during Low Season (636). Like the High Season provided for 

20 example herein, the Low Season is defined in the Tool and might represent the 
off-season at a particular resort. The fractional time dimension for Fraction 2 
(638) includes weeks 14-19 (640), four weeks during High Season and three 
weeks during Low Season (642). The fractional time dimension for Fraction 3 
(644) includes weeks 27-32 (646), four weeks during High Season and three 

25 weeks during Low Season (648). Finally, the time dimension for Fraction 4 
(650) includes weeks 40-45 (652), four weeks during High Season and three 
weeks during Low Season (654). Note, the Tool allows fractions to include a 
mix of fixed, floating and points time dimensions. With a fixed space 
dimension, each fraction illustrated in Figure 6b is associated with a particular 

30 unit. 
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A floating unit / fixed week usage type 656 is used to create a widget 
that includes an interest in a particular type of unit at a particular time, e.g., a 
two bedroom unit during weekl . A floating unit / floating week usage type 
658 is used to create a widget that includes an interest in a particular type of 
5 unit during a particular season, e.g., a two bedroom unit during High Season. 
A floating unit / fraction usage type 660 is used to create a widget that 
includes an interest in a particular type of unit for an amount of time that is a 
function of the selected time unit. Figure 6b illustrates a set of products based 
on usage types with a fractional time dimension. With a floating unit space 
10 dimension, each fraction illustrated in Figure 6b is associated to a particular 
type of unit. 

A whole ownership usage type 662 is used to create a widget that 
includes an interest in a particular unit in perpetuity. A pure points usage type 
664 is used to create a widget that is simply a quantity of points that represent 

1 5 the ability to use at least one unit at least one particular time that has the same 
or a lesser point value. Preferably, a pure points widget allows the usage of a 
plurality of rooms,"' at a plurality of resorts and at a plurality of times with the 
same or lesser point value. 

In further describing the operations associated with defining a usage 

20 type the various values used to define the usage types described above in 
regard to Figure 6a are referred to where appropriate below. 

Referring to Figure 6, the sales attributes definition operation 600a 
preferably includes: operation 602, defining a sales time unit; operation 604, 
defining a sales time unit count; operation 606, defining a sales increment; 

25 operation 608, defining sales time allocation; and operation 610 defining sales 
points. Generally, the sales attributes determine how PI is controlled. Like 
many of the operations discussed herein, the sales attribute definition 
operations may be performed at any time. Preferably, however, the sales 
attributes cannot be modified once the usage type is used to define a product. 

30 In operation 602, the user defines the sales time unit 666. The sales 

time unit defines the length of time for usage of the inventory that the 
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prospective purchaser may be purchasing. For example, referring to Figure 
6a, if the user is creating the fixed unit / fixed week usage type 626 the user 
selects the "week" sales time unit. The user would have previously defined a 
"week" time unit in the operations associated with the time unit definition 
5 discussed above with regard to Figure 4. Preferably, a set of sales time units 
that is the same as the set of previously defined time units is available to 
select from. 

If the sales time unit defined is "points," then the usage type being 
defined is "pure points." The remaining applicable attributes, described below 

10 in operations 604-618 are defaulted to "points." If the sales time unit is 

changed to something other than "points" then the defaulted attributes will be 
cleared of their "points" value. 

In operation 604, the user defines the sales time unit count 668. The 
sales time unit count defines how many sales time units are defined for a 

15 given use year. Referring to the fixed unit / fixed week usage type 626, the 
user could select 52 for the sales time unit count, representing 52, one "week," 
time units for a given year. The sales time unit count 668 defaults to a value 
based on the sales time unit 666 and the user may not select a value greater 
than the defaulted value. Preferably, the sales time unit count 668 defaults to 

20 its maximum allowed value when the sales time unit 666 is selected. For 

example, if the sales time unit 666 is "week" then the default sales time unit 
count 668 value is 52. The defaulted sales time unit count 668 will be 
determined by how many whole sales time units 666 fit into a use year 
(typically, 365 days). If the sales time unit 666 is greater than a day, than the 

25 sales time unit count 668 is (365/x) where x is the sales time unit's baseline 
factor (defined in operation 326). If the sales time unit 666 is less than a day, 
then the sales time unit count is (365*x) where x is the sales time unit's 
baseline factor (defined in operation 308). 

In operation 606, the user defines the sales increment 670. The sales 

30 increment 670 defines how many widgets are ultimately generated for the PI, 
as discussed below. A "widget" represents a discrete item in the product 
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inventory. Typically, a widget represents a timeshare interest in a piece of 
property, /.e., SI, as defined by the operations of this invention. However, a 
widget may represent timeshare interests in items besides property, e.g., a 4 
p.m. racquetball court time every week. 
5 Preferably, the sales increment 670 is defaulted to the same value that 

the sales time unit count 668 is defaulted to when the sales time unit 666 is 
selected. Preferably, the sales increment 670 is defaulted again to the value of 
the sales time unit count 668 if the user changes the value of the sales time 
unit count in operation 604. Preferably, the sales increment 670 cannot be a 

10 value that is greater than the sales time unit count 668. 

Preferably, if the sales increment 670 is modified to a value less than 
the value specified for the sales time unit count 668, then the user has set up a 
fractional product. When this occurs, then the sales time allocation 672 will 
be defaulted to "fraction", the pricing time allocation 678, described below in 

15 operation 614, is defaulted to "increment," and the contract time allocation 
682, described below in operation 618, is defaulted to "increment." The 
details of the time dimension for a fractional product, e.g.^ Fractions 1 -4 of 
Figure 6b, are defined in operations 1940 - 1944, as discussed below. 
Preferably, under any circumstance, the sales increment 670 must be greater 

20 than 0, 

In operation 608, a sales time allocation field 672 displays the usage 
types sales time allocation as defined by the sales time unit 666, sales time 
unit count 668 and the sales increment 670 attributes defined in operations 
602-606. Preferably, the valid valuer for the sales time unit allocation 672 are 

25 "fixed or floating," "fraction" or "points." 

Preferably, the sales time allocation 672 is defaulted to a value that is a 
function of the value specified in the sales time unit count 666 and the value 
specified in the sales increment 670. Accordingly, if the sales time unit count 
668 is equal to the sales increment 6760, then the sales time allocation 672 is 

30 defaulted to "Fixed or Floating." And, if the sales time unit count 668 is 
greater than the sales increment 670, then the sales time allocation 672 is 
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defaulted to "Fraction." As mentioned above, if the sales time unit 666 is 
"points" then the sales time unit allocation 672 is defaulted to "Points." The 
sales points attribute is not applicable if the sales time unit specified is 
"Points." 

5 In operation 610, the user defines whether the widgets, that will 

eventually be generated for the usage type, will have a points usage 
conversion. "Points" generally refers to a value that the usage type is 
accorded. For example, if a usage right, as discussed below, provides sales 
points 674 in certain circumstances for the product, then the owner of the 
10 timeshare interest is able to exchange points for the use of a variety of units 
provided that the units have an equal or lesser point value. 

The pricing attribute definition main operation 600b, preferably 
includes: operation 612, defining a pricing unit allocation 676; and operation 
614, defining a pricing time allocation 678. Generally, the pricing attributes 
15 determine how product inventory is priced. 

In operation 612, the user defines the pricing unit allocation 676. The 
pricing unit allocation 676 detemiines the pricing attributable to the space 
^jj^^jjg j^jj Pj.gjpgj.^jjjy^ ijj^ y^lU ^^i^^g ij^^ p^j^-^^ unit allocation 676 are 

unit, type and points. Any usage type with an "unit" pricing unit allocation 
20 676 will create a usage type with a "fixed" space dimension. Any usage type 
with a "type" pricing unit allocation 676 will create a usage type with a 
"floating" space dimension. And, any usage type with a "points" pricing unit 
allocation 676 will create a usage type with a "points" space dimension. 

In operation 614, the user defines the pricing time allocation 678. The 
25 pricing time allocation 678 determines the pricing attributable to the time 

dimension. Preferably, the valid values for the pricing time allocation 678 are 
increment, season and points. Any usage type with an "increment" pricing 
time allocation 678 will create a usage type with a "fixed" time dimension. 
Any usage type with a "season" pricing time allocation 678 will create a usage 
30 type with a "floating" time dimension. And, any usage type with a "points" 
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pricing time allocation 678 will create a usage type with a "points" time 
dimension. 

The contract attribute definition main operation 600c preferably 
includes: operation 616, defining contract unit allocation 680; and operation 
5 618, defining contract time allocation 682. Generally, contract attribute 
definition determines how product inventory is sold. 

In operation 616, the user defines the contract unit allocation 680. 
Preferably, the valid values for contract unit allocation 680 include unit, type 
and points. The contract unit allocation 680 determines what space dimension 

10 the widget will encompass. In operation 620, the user defines the contract 
time allocation 682. Preferably, the valid values for contract time allocation 
include increment, season and points. The contract time allocation determines 
what time dimension the widget will encompass. 

Preferably, in practical use of the Tool, only trained Tool users will 

15 define usage types in the Tool, such as those trained Tool users working for 
the Tool supplier. Representatives of the Tool supplier may learn, from the 
timeshare developer/manager, the desired functional requirements, will then 
define usage types based thereon. The set of usage types that a particular 
timeshare developer or manager wants to implement are defined functionally 

20 and then the Tool user defines those usage types in the Tool by defining the 
usage type attributes described in operations 600 - 620. This methodology is 
considered preferable because of the necessity to correctly define the 
attributes described in operations 600 - 620. Clearly, however, any user that 
is trained in operation of the Tool could potentially define usage types in the 

25 Tool. 

A particular usage type, defined in operations 600 - 620 may be deleted 
from the Tool at any time so long as it is not currently used in the definition 
of a timeshare product. In addition, a usage type may be activated or 
inactivated at any time. Activation of a usage type means that the usage type 
30 is available for the definition of a timeshare product. An inactivated usage 
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type that was previously used in the definition of timeshare product does not 
effect the previously defined timeshare product. 

Preferably, the usage type definition operations are implemented in a 
window, not shown herein, and preferably the workflow of the usage type 
5 definition window is left to right, similar to that shown in Figure 6a. The 
usage type setup window and associated datawindow fields, i.e., operations 
600 - 620, however, do not enforce this workflow. Accordingly, the 
operations 600 - 620 may be performed in any order the user of the Tool 
desires. 

10 Usage Right and Usage Policy 

Each product 145 will have a set of usage rights and usage policies 155. 
A usage right defines how a widget may be used once it is purchased: A usage 
policy defines how a particular right may be exercised by the purchaser. In 
prior art systems, usage rights and policies are managed on an ad hoc basis - 

15 it is up to a particular agent to check a timeshare owners contract or simply 
remember what rights the timeshare owner has. The present invention 
provides for user definable rights and policies which are associated with a 
particular product in the Tool. Accordingly, when the user is operating the 
Tool for inventory management the usage rights and policies associated with a 

20 particular product are part of the product and fully accessible by the Tool. As 
discussed below in conjunction with Figure 23, the rights are resolved 
periodically to provide the inventory manager with a current status of the 
rights available to a particular timeshare owner at a particular time and to 
automatically account for resolved rights in hotel availability. 

25 Preferably, the Tool includes a set of usage rights that may be 

customized for a particular product by the user. Usage rights and policies 
refers to a user-defined set of parameters that are defined in general terms to 
express "what," e.g., a points amount, a specific unit, or a unit of a specified 
unit type, "when," e.g., two months after contract closing, or in the High 

30 Season, and "where," e.g., a specific resort, an owner may exercise their 

"rights." Preferably, the set of usage rights includes: the reservation start and 
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end date, the usage start and end date, the length of stay, and the 
accommodation. The usage rights definition includes a boolean relationship, 
i.e., AND or OR, between different rights that allows the user to establish 
relationships between different rights for a given product. In addition, the 
5 usage rights definition operations allow the user to define a probability factor 
for each right that is useful in market planning and future availability planning 
in conjunction with blocking, discussed in more detail below. 

The following operations are described to create two exemplary rights 
for a particular product. "Right 1" is the right to a particular unit in a 
10 particular week. The definition of High Season was provided above as an 
example in the resort season calendar section. "Right 2" is the right to a 
particular type of unit in the High Season. Each right is defined separately. 
Accordingly, the following operations would have to be performed for each 
right. 

15 Figure 7 is a flowchart illustrating the exemplary operations involved 

in defined a usage right. In operation 700, the user selects a product for which 
they desire to define a usage right and policy for. In operation 710. the user 
selects whether they wish to add a new 12^3^^^ j.jg|^| product If so the 

user names the new usage right in operation 715. The names, by way of the 

20 example outlined above, are "Right 1" and "Right 2." 

In operation 720, the user selects the reservation start date. The 
reservation start date determines when an owner may request a reservation 
according to a particular right. Right 2 may allow the timeshare owner to 
make a reservation for a unit type during High Season one year prior to High 

25 Season. This means that the owner may first reserve the particular unit type 
for High Season starting one year prior to High Season. In operation 720, this 
is achieved by entering a formula that consists of a defined keyword and an 
expression - @seasonstart-365. The keyword for the reservation start date is 
@seasonstart wherein @seasonstart is defined as January 1 of the particular 

30 year. The expression is (-365) which represents 365 days before 

@seasonstart. Therefore, with @seasonstart-365 entered as the reservation 
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start date the owner has the right to make a reservation for his particular 
timeshare product 365 days before the first day of High Season. The 
keywords, starting with "@," are reserved in the Tool. 

In operation 725, the user selects the reservation end date. The 
reservation end date determines the last day in which an owner may request a 
reservation according to a particular right. Right 2 may allow the timeshare 
owner to make a reservation for a unit type during High Season up to 7 days 
before the end of High Season. Like operation 720, the reservation end date is 
entered by way of a formula that consists of a defined keyword and an 
expression. For Right 2 the keyword and expression is @seasonend-7. The 
keyword for the reservation end date is ©seasonend wherein @seasonend is 
defined as March 31 of the particular year. The expression is (-7) which 
represents 7 days before ©seasonend. Therefore, with @seasonend-7 entered 
as the reservation end date the owner had the right to make a reservation for 
15 his particular timeshare product 7 days before the end of High Season. 

Right 1 may allow the timeshare owner to make a reservation for unit 
101 during weekl of High Season between 13 months and I year before High 
Season. In operation 720, this is achieved by way of entering ©seasonstart - 
395 for the reservation start date. And, In operation 725, @seasonstart-366 is 
entered for the reservation end date. Therefore, the owner has a right to 
reserve a particular unit at a particular time between 395 days before High 
Season and 366 days before High Season. 

In operation 730, the user selects the usage start date. The usage start 
date determines the start of when the owner has a right to occupy. Referring 
25 to the example above the owner has a right to occupy a particular unit type 
during High Season for Right 2 and the owner has a right to occupy unit 101 
during weekl for Right 1. Accordingly, for Right 2 the usage start date, in 
operation 730, is defined as ©seasonstart. And. for Right 1 the usage start 
date, in operation 730, is defined as ©deedstart wherein ©deedstart is defined 
30 as the beginning of week 1 . 
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In operation 735, the user selects the usage end date. The usage end 
date determines the end of when the owner has a right to occupy. For Right 1 
the usage end date, in operation 735, is defined as @seasonend. And, for 
Right 1 the usage end date, in operation 735, is defined as @deedend wherein 
5 @deedend is defined as the end of weekl. 

In operation 740, the user defines the length of stay. As the name 
implies, the length of stay represents how long the owner may stay at the 
particular unit type for Right 2 or at the particular unit for Right 1 . 
Preferably, this value defaults to the time unit, e.g., "week", selected for the 

10 particular product. 

In operation 745, the user defines the probability that the member will 
exercise the specified usage right within the reservation window defined. 
Preferably, the sum of all probabilities for the rights associated with a product 
must equal 100%. The probability is a variable that may be used in 

15 conjunction with market planning to forecast future product inventory needs 
and to forecast future availability blocking requirements. 

In operation 750, the user defines the accommodation for the rights. 
For Right 2, the accommodation would be "unit type" and for Right I the 
accommodation would be unit. The particular unit type of Right 2 or the 

20 particular unit of Right 1 is defined during contract inventory selection 
discussed in conjunction with Figure 21 below. Preferably, the set of 
available accommodation values is unit, unit type and points. 

In operation 755, the user defines the Boolean operator which 
determines the interaction of various rights associated with the product. For 

25 example. Right 1 would be associated with a number, e.g., "1," and Right 2 
would be associated with a number, e.g., "2." The operator might be OR. 
Accordingly, the product includes 1 OR 2. This means that the product 
includes Right 1 or Right 2. So, if Right 1 is exercised the owner may not 
exercise Right 2. In contrast, if Right 2 is exercised the owner may not 

30 exercise Right 1 . 
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In operation 760, the user may elect to edit an existing usage right or 
define another new usage right for the product. After which the user may edit 
or define the reservation start date in operation 720, edit or define the 
reservation end date in operation 725, edit or define the usage start date in 
operation 730, edit or define the usage end date in operation 735, edit or 
define the length of stay in operation 740, edit or define the probability in 
operation 745, edit or define the accommodation in operation 750, and/or edit 
or define the operator in operation 755. In operation 765, the user may save 
the usage right that was edit or defined. 

If, in operation 770, the user does not choose to modify an existing 
usage right, then the user may choose to delete an existing usage right in 
operation 780. The user selects the usage right to delete in operation 785 and 
then deletes the usage right selected in operation 790. The user, in operation 
795, may choose to edit an existing usage right, delete an existing usage right, 
or create a new usage right. If so, the user starts the usage rights definition 
process from the beginning at operation 700. Otherwise, the user may end the 
usage rights definition operations at operation 799. 

A policy defines how a particular right may be exercised. For example, 
referring to Right 1 and Right 2 presented for example above, the owner may 
have a Policy 1 that allows occupation and a Policy 2 that allows the product 
to be placed in a rental program. A rental program, for example, allows the 
timeshare owner to rent out his interest for a particular year. Referring again 
to operation 710, if the user does not elect to add a new usage right, then the 
user may modify an existing usage right in operation 770. Policies are defined 
for each right associated with a product in substantially the same way as usage 
rights are implemented as discussed above. The policies, however, are 
defined in a business rules engine that is associated with the Tool. 

Preferably, the usage rights and policies definition operations are 
implemented in a window and preferably the workflow of the usage rights and 
30 policies widows, not shown herein, is left to right. The usage rights and 

policies windows and associated datawindow fields, i.e., operations 700 - 799, 
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however, do not enforce the workflow. Accordingly, the operations 700 - 799 
may be performed in any order the user of the tool desires. 
Timeshare Product 

Generally, timeshare product definition refers to adding or modifying a 
5 product in the tool and is one of main operations 350 of the overall product 
definition operations. The timeshare product definition operations utilize the 
usage types and usage rights discussed above to define particular products. 

Figure 8 is a flowchart illustrating the exemplary operations involved 
in timeshare product definition. In operation 805, the user determines if a new 
10 product will be created. If so, in operation 805, the user selects a previously 
defined usage type for the new product. In operation 815, the user names the 
product. In operation 825, the user determines if the product will have a 
perpetual life. 

If the product will not have a perpetual life, the user sets the use term 

15 start date in operation 860. Preferably, the use term start date must be 

specified. The use term start date determines the first possible day that any 
piece of inventory-defined by this product can be used by the timeshare owner 
or member. In operation 865, the use term ^^pJi^^tiQu ^^|,^ s^t. The use 
term expiration date determines the date the product expires on. In operation 

20 867, the use term in years is defined. The use term in years determines the 

use term of the product in years starting in the year of the owner first use date. 
The owner first use date is defined during contract inventory selection as 
discussed below in conjunction with Figure 21. 

If the use term is perpetual, then the use term of the product being 

25 defined has no expiration and will exist in perpetuity. As a result, the use 
term years field, in operation 867, and the use term expiration date field, in 
operation 865, will be disabled. Preferably, if values are already specified for 
the use term years field and the use term expiration date field, then the user 
may only check the use term never expires attribute in operation 825 as long 

30 as no product inventory widgets derived from this product are sold yet. If no 
widgets are sold, then the values from the use term years and use term 
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expiration date fields will be cleared. However, if a widget has been sold the 
use term never expires cannot be redefined to "never expires." Product 
inventory for these non-expiring products in never reset. 

If the use term is not perpetual, then use term years, in operation 867, 
and/or the use term expiration date, in operation 865, must be specified. If 
only the use term years is specified, then the product inventory will be reset 
every 'n' years for perpetuity. The owner of the widget will have rights to 
that product inventory for the 'n' years determined by the use term years 
attribute starting on the owner first use date specified at contract sales time for 
the widget. After 'n' years from the owner first use date, the product 
inventory is available for use by another owner. However, the next owner 
does not have to use the product as soon as it is available for use again. The 
next owner may choose to specify an owner first use date that leaves a gap 
between the previous owner's usage term and the new owner's usage term. 
15 This time may be lost if another product does not use the gap in time. 

If only the use term expiration date, in operation 865, is specified, then 
the product inventory widget is sold once and never reset. The owner of the 
widget will have rights to that widget until the use term expiration date. If 
both the use term expiration date, in operation 865, and the use term years, in 
20 operation 867, is specified then the product inventory widget will reset every 
'n' years until the use term expiration date. The owner of the widget will 
have rights in that widget for 'n' years until the use term expiration date. 
After 'n' years the product inventory is reset and the widget is again available 
for sale. 

25 If the product is defined as perpetual in operation 825 or after the use 

term start date, use term end date, and use term in years are defined in 
operations 860, 865 and 867, then the user determines if the frequency for the 
product is annual. The frequency determines how often an owner of a product 
inventory widget has rights to use the widget. For example, an annual 

30 frequency gives the owner rights for every year. If the product does not have 
an annual frequency, then the user defines the frequency in operation 853. For 
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example, the frequency may be set to biennial which means that the owner has 
rights every other year. In operation 855, the user sets the frequency start 
year. The frequency start year determines the start year for the selected 
frequency other than "annual." In addition, it is the starting point for the 
5 determination of each occurrence of a product's use year which is used in the 
resort season calendar. Preferably, the valid values for the frequency attribute 
defined in operations 830, 853 and 855 are annual (every year), biennial 
(every other year), triennial (every three years) and quadrennial (every four 
years). 

10 In operation 835, after determining the frequency in operations 830, 

853 and 855, if a points usage type is selected in operation 810 or the sales 
time unit, defined in operation 610, is defined as "points," then the user may 
add or delete a points package in operation 840. If the user chooses to add a 
points package in operation 840, then the user can define a points package. 

15 To define a new points package, in operation 845, the user sets the point 
increment. The points increment is the number of points that the specific 
points package represents. Points packages may only be sold in valid 
increments defined by one or many points packages. If the user deletes a 
points package then the currently selected points package is deleted. 

20 A points product is any product that is associated with SI that include 

an equivalent points value. A pure points product is a type of product that 
allows simple ("pure") point amounts to be sold without having to back the 
points with physical inventory or without linking any other requirement in any 
way to the product. A resort is assigned an overall amount of pure points to 

25 divide up and sell as pure points products. A points package is the increments 
via which a points product can be sold. Every points product needs at least 
one package (standard) defined in order to allow selling. Points can be bought 
as multiples of the standard points package or as individual non-standard 
points packages. In addition, an extra points package can be defined to allow 

30 selling of extra points above and beyond a package. For example, if the 
standard is defined as 1000 points and an extra is defined as 100 points, a 
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buyer could purchase 1200 points (1 standard + 2 extras); if no extra is 
defined, buyers are limited to purchasing 1000 points, 2000 points, etc., which 
are increments of the standard points product of 1000 points. 

Finally, in operation 850, the user may add comments to the product. 
5 The comments operation 850 allows the user to describe product attributes 
that may not be described elsewhere. The comments may include the 
distribution for the product 850a and a general description of the product 
850b. 

If, in operation 805, discussed above, the user is not creating a new 

10 product, then the user may modify an existing product in operation 870. In 
operation 875, the user selects the product to modify. Afterward, the user 
moves to operation 825. Operation 825 and the following operations are 
described in detail above. 

Preferably, the product definition are implemented in a window and 

15 preferably the workflow of the timeshare product definition window, not 

shown herein, is left to right. The timeshare product definition window and 
associated datawindow fields, i.e., operations 800 - 850, however, do not 
enforce the workflow. Accordingly, the operations 800 - 850 jyj^y 
performed in any order the user of the tool desires. 

20 Membership 

Membership is an optional or mandatory enhancement sold in 
conjunction with a widget Memberships alter the usage right of the stand- 
alone widget. For example, the widget purchased alone may have usage rights 
at resort A exclusively. However, the same widget purchased with a gold 

25 membership expands the usage rights to cover rights in Resorts A, B and C, 
Memberships are preferably renewed by the buyer within some time period, 
typically a year. 

Figure 9 is a flowchart illustrating the exemplary operations associated 
with adding a membership to a product. In operation 900, the user selects the 
30 add-on membership icon from the main menu to start the operations of adding 
on a membership to a product. In operation 905, the user selects a product to 
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add a membership to. In operation 910, the user determines if a new 
membership will be added to the product. If a new membership will be added, 
then the user sets the renewal frequency in operation 915. The renewal 
frequency determines the recurring frequency of the membership in sales 
5 years. For example, if the frequency is "annual," then the membership can be 
renewed every year; if the frequency is "biennial," then the membership can 
be renewed every other year. 

In operation 920, the user sets the membership price. The membership 
price is the price of the membership for the specified renewal frequency. In 

10 operation 925, the user may set the membership required flag. The 

membership required flag determines whether the defined product requires 
membership selection during contract inventory selection, as discussed below 
in conjunction with Figure 21. If the flag is set, then only one membership 
must be associated for the defined product in the contract. 

15 Each add-on membership for a particular product includes its own set 

of usage rights. Accordingly, operations 930-945 allow the user to define a 
set of usage rights for the particular product and associated add-on 
membership. In operation 930, the user may choose to add a new usage right 
to the membership. Operation 930a, takes the user to the start of the usage 

20 right definition operations associated with Figure 7, as described above. In 
operation 935, the user may select to delete a usage right in which case the 
user selects a usage right that is deleted in operation 935a. In operation 940. 
the user may select to modify an existing usage right in which case the usage 
right definition operations, as discussed above in conjunction with Figure 7, 

25 are accessed in operation 940a. The newly defined membership and usage 

rights may be save in operations 945 and 945a. Or, the user may select to end 
the add-on membership definition process in operations 950 and 950a. 

If, in operation 910, the user does not choose to add a new membership 
to the product, then the user may select a previously defined membership for 

30 the product in operation 955. Then, the user may choose to delete the 

membership in operation 960 or modify the membership in operation 965. If 
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deletion is selected, then the previously selected membership is deleted in 
operation 960a and the user may start the add-on membership process anew at 
operation 900. If the user chooses to modify the membership, then the user 
performs operations 915-945 as discussed above. 
5 Hotel and Sales inventory Definition 

Hotel Inventory ("HI") preferably includes resorts, clusters, room 
types, and rooms and buildings, locations and attributes. HI represents all of 
the inventory that can be used by both timeshare owners and transient guests. 
An exemplary block diagram illustrating the HI for the Sunbay Resort is 
10 shown in Figure 10 and discussed in more detail below. Note, the HI 

illustrated in Figure 10 is the same HI illustrated at reference numeral 1 15 in 
Figure 1. 

Sales Inventory ("SI") preferably includes resorts, unit types, and units 
along with associated phases, buildings, and attributes and is the space 
15 dimension of product inventory. The entities that populate SI are the logical 
entities that can be sold as part of a product. The entities of SI are "logical" 
because they represent what may be sold as opposed to what may be used, i.e.. 

Figure 1 1 and discussed in more detail below. Note, the SI illustrated in 
Figure 1 1 is the same SI illustrated at reference numeral 1 10 in Figure 1 

The following is one example of the difference between SI and HI. For 
example, a three bedroom unit may be composed of a two bedroom unit and a 
one bedroom unit with a door in between. This arrangement is referred to as a 
"lock-out." The three bedroom unit is sold, however, the owner may choose 
25 to only use the two bedroom unit and do something else with the one bedroom 
unit, e.g., rent or place in exchange program. The three bedroom unit for sale 
comes from SI and the two bedroom unit and one bedroom unit for use come 
from HI. 

Figure 12 illustrates the exemplary hierarchical operations involved in 
30 defining HI and SI. The HI and SI definition operations include: defining a 
resort or hotel in operation 1210; defining room types in operation 1220; 
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defining rooms in operation 1230; defining unit types in operation 1240; 
defining units in operation 1250; and defining locations of interest that are 
near the resort, in operation 1260. HI is primarily defined in operations 1210, 
1220 and 1230 and SI is primarily defined in operations 1240, 1250 and 1260. 
However, many of the attributes defined in the operations, especially those 
associated with operation 1210, are related to both HI and SI. 

Figure 10 is a block diagram illustrating an exemplary HI for the 
Sunbay Resort 1002. The Sunbay Resort 1002 HI has three exemplary 
clusters: three bedroom rooms 1004, two bedroom rooms 1006 and standard 
rooms 1008. i.e., one bedroom. Clusters are generally groupings of rooms 
with a shared characteristics such as the number of rooms. The clusters each 
include associated room types. The three bedroom cluster 1004 includes a 
three bedroom ocean view room type 1010. The two bedroom cluster 1006 
includes a two bedroom ocean view room type 1012 and a two bedroom golf 
course view room type 1014. The standard room type cluster 1008 includes a 
one bedroom studio room type 1016. Additionally, the room types have 
associated rooms. The three bedroom ocean view room type includes two 
rooms, 105 (1018) and 106 (1024), that have three bedrooms and an ocean 
view. Note, room 105 (1018) is composed of two rooms, a two bedroom 105 A 
(1020) with an ocean view and a one bedroom 105B (1022) that are locked-off 
from each other. The two bedroom ocean view room type includes three 
rooms, 101 (1026), 103 (1028) and 105A (1030) that have two bedrooms and 
an ocean view. The two bedroom golf course view room type includes three 
rooms, 102 (1032), 104 (1034) and 109 (1036). that have two bedrooms and a 
golf course view. Finally, the studio room type includes three rooms 105B 
(1038), 108 (1040) and 110(1042). 

Figure 1 1 is a block diagram illustrating an exemplary SI for the 
Sunbay Resort. The Sunbay Resort 1002 SI has two unit types: three 
bedroom 1 104 and two bedroom 1 106. The unit types each include associated 
units. The three bedroom unit type includes unit 105 (1 108). The two 
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bedroom unit type includes unit 101 (1110), unit 102 (1112), unit 103 (1114) 
and unit 104 (1116). 

The following discussion provides a preferable set of operations to 
define the HI and the SI for a resort such as the Sunbay Resort 1002. The 
5 definition of HI results in, for example, a representation in the Tool of the 

Sunbay Resort 1002 as illustrated in Figure 10. The definition of SI results in, 
for example, a representation in the Tool of the Sunbay Resort 1002 as 
illustrated in Figure 1 1 . However, both HI and SI typically include more 
attributes, as discussed below, than is shown in Figures 10 and 11. 
10 Figure 13 illustrates the exemplary operations involved in defining the 

Resort or Hotel portion of HI and SI, such as the Sunbay Resort 1002, 
including: providing Resort information in main operation 1300a, defining 
clusters in main operation 1300b, defining phases in main operation 1300c, 
defining buildings in main operation 1300d, defining floors in main operation 
15 13 OOe, defining proximity in operation 1 3 OOf and defining resort attributes in 
operation 1300g. Main operations 1300a-1300g create database "tables." 
Each table is comprised of a defined set of attributes that define the 
components, cg.^ a 'cluster" or a "phase," of a resort or hotel 

In main operation 1300a, the user defines general information 
20 pertaining to the resort or hotel being setup. Note, this document generally 
refers to "resorts" or "hotels," however, the Tool is not limited to resort or 
hotels. Rather, the Tool may be used to manage any entity with a timeshare 
interest. In operation 1302, the table includes a resort Id. This is the primary 
key of the resort table. The resort Id is what other tables link to when setting 
25 up the entire resort. In operation 1304, the table includes an organization Id. 
This is the foreign key (hereinafter "FK") to the organization table. As 
discussed above the organization is the high level entity that includes the 
resort. An FK is a database implementation parameter. In operation 1306, the 
user defines a resort number. The resort number is a unique number to 
30 identify the resort within the organization. In operation 1308, the user defines 
a resort code which is a unique code to identify the resort within the 
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organization. In operation 1310, the user defines a resort name, e.g., 
"Sunbay." In operation 1312, the user provides a description of the resort. In 
operation 1314, the user defines a planning horizon for the resort. The 
planning horizon is the number of days in the planning horizon of the resort. 
The planning horizon number is only used for hotel resorts and it is used in 
calculating how far in advance to create resolved usage rights and availability, 
as discussed in more detail below. A hotel resort has both timeshares owners 
and transient guests. In operation 1316 the user defines a historic horizon 
which is the number of days to hold historic hotel resort information. 

In operation 1318 the user defines a type. Preferably, the values for 
type include sales, hotel and both. A "sales" value for the type means the 
resort is strictly a timeshare resort - there will not be any transient guests. A 
"hotel" value for the type means the resort is strictly a hotel - there will not 
be any timeshares. Finally, a "both" value for the type means the resort is 
15 both a timeshare property and that it will also have transient guests. 

In main operation 1300b, the user defines the clusters associated with 
the resort defined in main operation UOOa. In operation 1020. the table 
includes 3. cluster Id. This is tlic pi-jjjjg^|*y j^^y the cluster t^ble Xtie cluster 
Id provides a linking mechanism to associate with other tables. In operation 
1322, the table includes a resort Id. This is the FK to the resort table. If the 
Sunbay Resort 1002 is being defined, then the resort Id included in operation 
1322 would be the same resort Id used to identify the Sunbay Resort defined 
in operation 1302. Note, clusters are not defined for sales only resorts. 

In operation 1324, the user defines the cluster code which is a unique 
code to identify the cluster within the resort. In operation 1326, the user 
defines a cluster name, e.g., "three bedroom." In operation 1328, the user 
provides a description of the cluster being defined. For example, the 
description may be "three bedroom units." In operation 1330, the user 
provides a display order which is the order to display values in a drop down 
window. For example, if unit 101, 103. 102 and 104 are going to be presented 
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in a window, then the display order presents them as 101, 102, 103 and 104 or 
as 104, 103, 102 and 101. 

In main operation 1300c, the user defines any phases associated with 
the resort. A phase is simply a phase in a development. For example, phase 1 
may include 20 units and is built first. Phase 2, includes 10 units and is built 
after phase 1 is complete. In operation 1332, the phase table includes a phase 
Id. This is the primary key of the phase table. The phase Id provides a 
linking mechanism to associate with other tables. In operation 1334, the 
phase table includes a resort Id. This is the FK to the resort table. If the 
Sunbay Resort is being defined, then the resort Id included in operation 1334 
would be the same resort Id used to identify the Sunbay Resort defined in 
operation 1302. 

In operation 1336. the user defines a phase code which is unique code 
to identify the phase within the resort. In operation 1338, the user names the 
phase currently being defined. In operation 1340, the user provides a 
description of the phase. In operation 1342, the user provides the display 
order which is the order to display values in a drop down window. 

In main operation 1300d. the user defines the buildings associated with 
the resort. In operation 1344, the table includes a building Id. This is the 
primary key of the building table. The building Id provides a linking 
mechanism to associate with other tables. In operation 1346, the table 
includes a resort Id. This is the FK to the resort table. If the Sunbay Resort is 
being defined, then the resort Id entered in operation 1346 would be the same 
resort Id used to identify the Sunbay Resort defined in operation 1302. 

In operation 1348, the user defines a building code which is a unique 
code to identify the building within the resort. In operation 1350, the user 
defines a building name. In operation 1352, the user provides a description of 
the building. 

In main operation 1300e, the user defines the floors associated with the 
buildings defined in operation 1300d. In operation 1354, the user defines a 
floor Id. This is the primary key ofthe floor table. The floor Id provides a 
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linking mechanism to associate with other tables. In operation 1356, the user 
selects a building Id. This is the FK to the building table. In operation 1358, 
the user defines a floor code which is a unique code to define the floor within 
the building. In operation 1360, the user defines a floor name. In operation 
5 1 362. the user provides a description of the floor. In operation 1364, the user 
defines a display order which is the order to display values in a drop down 
window. 

In main operation 1300f, the user defines a proximity which is used to 
determine points of interest that are located near the resort. In operation 
10 1366, the user defines a location which is a particular site or point of interest 
that is located near the resort, e.g., "Joe Louis Arena - the home of the Red 
Wings." In operation 1368, the user inputs a proximity which is a description 
that references the distance in miles to the specified location from the resort, 
e.^., "10 miles." 

In main operation 1300g. the user defines a resort attribute. Exemplary 
resort attributes include a swimming pool and a gold course. In operation 
1370. the user defines a code which is a unique code associated with the 
attribute. In operation 1372, the user names the attribute being defined e g 
"swimming pool." And, in operation 1374, the user provides a description of 
20 the attribute. 

Figure 14 illustrates the exemplary operations involved in setting up a 
room type for a HI resort. In operation 1405, the user defines a room type Id 
which is the primary key of the resort table. In operation 1410, the user 
specifies the resort Id of the resort that the room type is being defined for. In 

25 operation 1415, the user names the room type, e.g., "3 Ocean" 1010. In 

operation 1420, the user specifies the cluster Id for the cluster that the room 
type being defined belongs to, e.g, "3 bedroom" 1004. In operation 1425, the 
user provides a room type code which is a unique code that used to identify 
the room type. In operation 1430, the user provides a description of the room 

30 type, e.g., "three bedroom with a master suite and an ocean view." 
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In operation 1435. the user sets a flag that determines if the room type 
should be included in run of the house operations. Run of the house is a type 
or reservation that includes any room in the resort. The flag allows the room 
type to be included in ROH. In operation 1440, the user defines the lock-off 
status of the room type. Preferably, the allowable values for the lock-off 
status include non-lock-off, lock-off type, or part of a lock-off. A lock-off 
refers to a room that includes a door directly to an adjacent room wherein the 
two rooms may be sold or rented separately or together. 

Figure 15 illustrates the exemplary operations involved in defining a 
room for HI, including: providing general room information in main 
operation 1500a, providing the sleeping arrangements for the room in main 
operation 1500b, associating the room to sales inventory in main operation 
1500c, providing occupancy dates for the room in main operation 1500d. 
defining lock-off rooms in main operation 1 500e, and providing room 
15 attribute information in main operation ISOOf. 

In main operation 1500a, the user defines general room information for 
the room being defined. In operation 1502, the user selects the resort that the 
room belongs to. In operation 1504, the user selects the cluster within the 
resort that the room is a part of. In operation 1 506, the user selects the room 
20 type for the room being defined. 

In operation 1508, the user defines a room number of the room, 
typically the same room number that is on the door to the room. In operation 
1510, the user names the room, e.g., the "Blue Room" or the "Victorian 
Room." In operation 1512, the user provides a description of the room. In 
operation 1514, the user selects the building that the room is in. In operation 
1516, the user selects the floor that the room is on. In operation 1518, the 
user selects the business entity that receives the revenue for the room. 

In main operation 1500b. the user defines the sleeping arrangements for 
the room. In operation 1519, the user defines the number of beds in the room. 
In operation 1520, the user defines the number of people that the room can 
accommodate in non-shared accommodations in individual beds. In operation 
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1522. the user defines the number of people that the room can accommodate in 
shared accommodations. For example, for a room with a queen size bed and a 
twin size bed, the number of beds in the room is two, the number of people 
that the room can accommodate in non-shared accommodations is two. and the 
number the room can accommodate in shared accommodations is three people 
In main operation 1500c, the user defines the SI entities associated with 
the particular room being defined. In operation 1524, the user selects the 
resort name, e.g., "Sunbay" 1002. of the associated sales inventory unit, if 
applicable. In operation 1526, the user selects the associated timeshare unit 
type, e.g., three bedroom 1 104, if applicable. In operation 1528, the user 
selects the associated SI timeshare unit, e.g., unit 105 (1 108). 

In main operation 1 500d, the user defines the occupancy information 
for the room. In operation 1530. the user defines the first day that the room 
can be occupied. For a resort already in existence this date is often the same 
15 date that the HI is being defined. However, for a new resort, this date is the 
first date that the room will be available when the resort is completed. This 
date is also important for resorts-that are not currently using the Tool but will 
begin using the Tool in the future. In operation 1 532, the user defines the last 
day that the room can be occupied. 

In main operation 1500e, the user defines the lock-off status of the 
room. A lock-off is a room that may be partitioned into smaller subdivisions 
with a lockable door separating the partitions. Referring to Figure 10, room 
105 (1018) is a lock-off In operation 1534, the user defines the room type 
that the room belongs to in the lock-off situation. In operation 1536, the user 
25 defines the rooms that belong to the lock-off Referring again to Figure 10, 
room 105 A (1020) and room 105B (1022) belong to the lock off 

In main operation 1500f, the user defines the room attribute 
information for the room. In operation 1538, the user is presented with a 
display of room attribute categories. An example of a room attribute is view, 
30 e.g., "ocean" view and "golf view illustrated in Figure 1 0. Other attributes 
include, for example, ski-out, in-room hot tub, and private master suite. In 
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operation 1540, the user selects the attributes that describe the attributes of 
the room. For example, room 105 (1018) has an ocean view. 

Figure 16 illustrates the exemplary operations involved in defining a 
unit type for SI. In operation 1610. the table includes a unit type Id. This is 
the primary key of the unit type table. The unit type Id provides a linking 
mechanism to associate with other SI tables. In operation 1620, the table 
includes a resort Id. This is the FK to the resort table. If the SI for the 
Sunbay Resort 1002 is being defined, the resort Id included in operation 1620 
would be the same resort Id used to identify the Sunbay Resort defined in 
operation 1302. Note, the resort definition parameters defined in operations 
1300 - 1374 for HI, discussed above with regard to Figure 13, are also utilized 
as part of the SI. 

In operation 1630, the user defines a unit type code. The unit type code 
is a unique code for the unit type being defined and is unique across the 
15 resort. In operation 1640, the user defines the unit type name which is the 
name given to the unit type being defined, e.g., "3 bedroom" 1 104. In 
operation 1650, the user defines the unit type description which is additional 
dctd-il for th.^ 1111111 type* In. opGr&tioii 1660, tiic user {}g£][j|^g tJig gqu^j-^ £'^^^^g^ 
for the unit type which indicates the size of the unit type. 

Figure 17 illustrates the exemplary operations involved in defining a 
unit for SI. Generally, in main operation 1700a general unit information is 
defined, in main operation 1700b the sleeping accommodations for the unit are 
defined, in main operation 1700c SI to HI mapping information is defined and 
in main operation 1700d unit attribute information is defined. 
25 Referring now to the general unit information main operation 1 700a, in 

operation 1702 the resort that the unit is being defined for is displayed. In 
operation 1704, the user defines the unit type to which the unit belongs, e.g., 
"3 bedroom." In operation 1706, the user defines the unit number of the unit 
being defined, e.g., "105." In operation 1708, the user defines a name for the 
30 unit being defined, e.g., "Presidential Suite." In operation 1710, the user 
provides a short description of the unit being defined. 
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In operation 1718, the user defines the check-in day for the unit. In 
operation 1720, the user defines the square footage of the unit. The square 
footage is used when maintenance fees are calculated. In addition, the square 
footage is used in calculating the property taxes for the unit. Finally, in 
5 operation 1 722, the user defines whether the unit will have an escrow account 
associated with it the unit is attached to a contract during the contract 
inventory selection operations discussed below. 

Referring now to the sleeping accommodation main operation 1700b, in 
operation 1724, the user defines the total number of beds in the unit. In 

10 operation 1 726, the user defines the total number of people that the unit will 
acconamodate in non-shared sleeping accommodations. Finally, in operation 
1728, the user defines the number of people that the unit will accommodate in 
shared sleeping accommodations. For example, if the unit includes a queen 
size bed in a master bedroom, two twin beds in a shared room, and a pull-out 

15 couch that sleeps two in the Uving room, then the total number of beds in the 
unit is four, the total number of people that the unit will accommodate in non- 
shared sleeping acconmiodations is four, and the number of people that the unit 
will accommodate in shared sleeping accommodations is six. 

Referring now to the SI to HI mapping main operation 1700c, in 

20 operation 1 730 the user defines the hotel resort, defined in main operation 

1300a-1300g. that the unit is a part of The selection of the resort dictates the 
choice of buildings in operation 1714. In operation 1732, the user defines the 
hotel room type, defined in operation 1400-1440, that this unit is a part of 
The selection of the resort in operation 1730, dictates the available room types 

25 in operation 1732. Finally, in operation 1734, the user selects the hotel room, 
defined in main operations 1500a - 1500f that the unit being defined is 
associated with. The selection of the room type in operation 1732, dictates the 
available rooms in operation 1734. 

Referring to Figure 1, an exemplary HI to SI mapping configuration for 

30 the Sunbay Resort 135 is illustrated by reference numerals 1736 and 1738. 

Reference numeral 1736 shows that room 101 (140) of HI (115) is mapped to 
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unit 101 (120)of SI (110) and reference numeral 1738 shows that room 102 of 
HI (115) is mapped to unit 102 (172) of SI (110). 



Product Inventory 

5 Product inventory ("PI") is created through the association of products 

to SI- PI cannot be defined until at least one product is defined and SI is 
defined. The definition of both products and SI is discussed above. PI 
definition includes two hierarchical operations: product and SI selection and 
product and SI association. The product and SI selection operation requires 

10 the user to select the product and a set of SI entities that may later be 

associated. Preferably, the product is selected via a dropdown datawindow 
that will list all defined products for the organization. Preferably, the set of SI 
entities are selected by specifying some definitive search criteria that will 
return all valid SI entities that match the criteria. From the list of SI entities, 

15 the user is able to multi-select specific SI entities to associate to the product. 

After the product and SI inventory selection operations, the product and 
SI inventory selected are associated. The association operation creates the 
product inventory, i.e., the set of timeshare widgets that may be sold. After 
the association process is initiated, the user is prompted for some requisite as 

20 well as some optional information. The optional information is dependent 
upon the type of product being associated as defined by its usage type. The 
optional information includes: definition of a product calendar, definition of 
maintenance increments, definition of time allocation details (fractions only), 
attribute initialization, and definition of point allotments and point totals. The 

25 optional information may also be defined or modified at a later time. 

Figure 1 8 is a flowchart illustrating the exemplary operations involved 
in product and SI entity selection. In operation 1805, the user selects a 
previously defined product. Preferably, a list of all of the defined products for 
an organization is provided for the user to select fi-om. Following product 

30 selection, the user defines a search criteria 1807 for the SI entities that may 
later be associated with the product. 
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In operation 1810, the user selects a resort. Preferably, the resort is the 
only mandatory search criteria that the user must enter. If no other search 
criteria is specified, then the search, in operation 1855 (discussed in more 
detail below), would search the resort selected for any entities that match the 
5 product selected in operation 1805. For example, if the product selected 
included a two bedroom unit and the resort selected is Sunbay Resort 1002, 
then the SI entities found in operation 1805 matching the search criteria may 
include unit 101 (1110), unit 102 (1112), unit 103 (1114) and unit 104 (1116). 
The user, however, may further define the search criteria in operations 1815 - 
10 1850. If a product with a pure points usage type is selected in operation 1805, 
then the following additional search criteria will preferably not be available to 
the user. 

In operation 1815, the user may select a unit type to search for. In 
operation 1820, the user selects the unit type, preferably from a list of 

15 available unit types. In operation 1823, the user may select a phase. In 

operation 1830, the user selects the phase, preferably from a list of available 
phases. In operation 1835, the user may select a building. In operation 1840, 
the building is selected, preferably firom a list of available buildings. In 
operation 1845, the user may select a unit. In operation 1850, the unit is 

20 selected, preferably from a list of available units. The operations 1805-1850 
are preferably presented in drop down datawindows. 

For operations 1810 - 1850, the lists of available search criteria is 
dynamically updated based on the previously selected search criteria. For 
example, after a resort is specified in operation 1810, the unit type, unit, 

25 phase, and building fields, associated with operations 1815-1850 are filtered to 
display only those entities that are associated with the selected resort. As a 
further example, if a two bedroom unit type 1 106 is defined as a search criteria 
in operation 1820, the units available for selection in operation 1850 are unit 
101 (1110), unit 102(1112), unit 103 (1114) and unit 104(1116). 

30 The resort selection in operation 1810 is required because of the 

potential calendar conflicts between resorts. A common calendar is implied in 
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a single association operation because time is one dimension of defining 
product inventory. As a result, when association occurs, as discussed below, 
the set of selected SI entities must have consistent season definitions. This 
cannot be guaranteed unless all selected SI entities are linked to the same 
5 resort. Each resort defines the season it will utilize in its calendar during the 
resort season calendar definition operations as discussed in conjunction with 
Figure 5. 

After any of the search criteria definition operations 1810 - 1850, the 
user may start the search in operation 1855. If the user elects to begin the 

10 search, in operation 1860, the Tool searches for SI that matches the search 
criteria. If no SI is found that matches the search criteria then the user may 
specify a new search beginning anew in operation 1800. If SI entities are 
found matching the search criteria, then the Tool returns a list of all SI entities 
matching the search criteria. The list displays the resort, unit type, unit, phase 

15 and building of the matching SI. In operation 1875, the user may associate the 
product selected in operation 1805 with any of the displayed SI entities. The 
user may, however, elect to cancel the association operation in operation 1880 
and close the association window, not shown, in operation 1895. 

Preferably, the same product cannot be associated to the same SI entity 

20 more than once. The same SI entity, however, may be associated to more than 
one product- For example, if product 1 includes a two bedroom unit type 1 106 
and product 2 includes unit 101 (1110), then product 1 may only be associated 
to the two bedroom SI 1106 once. However, unit 101 may be associated to 
both product 1 and product 2. If product 2 is sold, then unit 101 is 

25 automatically disassociated from product 1 by the Tool. 

In addition, the product can only be associated to a selected SI entity if 
the product selected to be associated with the SI displayed in operation 1865 
have time units that are complementary to one another. To be complementary, 
the time units of all products associated to SI entity must share a lowest 

30 common factor that is also a time unit of one of the associated products. The 
lowest common factor cannot represent the single day time unit. For example. 
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products with time units of 1, 2, 4, 6, 8, and 10 days or 3, 6, 15, and 21 days 
satisfy the lowest common factor requirement because all combinations of the 
time units are evenly divisible by 2 or 3 days respectively which are also both 
time units of the associated products. Products with time units of 1, 4, 6 and 
5 12 days, however, cannot be associated to the same SI unit because the set 
does not satisfy the lowest common factor requirement. The lowest common 
factor is 2 which is not a time unit of any of the products. In addition, week 
based products may only be associated to units that have a specified check-in- 
day value, see Figure 5. 

10 Figure 19 is a flowchart illustrating the exemplary operations involved 

in a product to SI association for non "pure points" products. At the 
conclusion of the non pure points product association operations 1910-1970 as 
set of widgets available for sale is defined. 

In operation 1910, the user may define a product calendar Default 

15 resort calendars are defined for each resort per defined time unit. The resort 
calendars specify the distribution of the particular calendar's time unit 
increments into groupings known as seasons as discussed above along with 
Figure 5. When a product is associated with a piece of SI, the user has the 
option of either using the default resort season definitions for the specified 

20 product's time unit or a specific product season calendar may be created. 

If the default resort season definitions are used then any changes made 
to these default season definitions at the resort level, discussed above along 
with Figure 5, will be validated against and applied to the products utilizing it. 
However, if the product defines its own season definitions, then the product 

25 specific calendar will be completely isolated from the resort calendar. Any 
changes made to the resort calendar will not be reflected in these products. 
The product season definitions simply allow the user to redistribute the time 
unit increments into different season groupings than was defined by the resort. 
The product definition must still account for the full subset of resort defined 

30 seasons and the product cannot add additional seasons to the definition. It is 
simply an increment redistribution process. 
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If the user opts to specify product season definitions, then the new 
product season definitions need to be accessible to the subsequent operations 
of non pure points product association because the subsequent operations rely 
on the season definitions. The operations necessary to specify product season 

5 definition are substantially the same as the operations discussed above in 
regard to the resort season calendar definition, see Figure 5. 

In operation 1920, the user may define a maintenance increment for the 
product association. The space, e.^., unit 101 (1110), that defines the space 
dimension of each piece of product inventory must be maintained on a regular 

10 basis. To facilitate the control of maintenance time requirements, the Tool will 
allow the user to define maintenance time increments that designate widgets of 
PI over the specified maintenance increments as unavailable for sale. 
Moreover, the Tool allows the user to specify more than one increment as 
maintenance. The set of maintenance increments are defined per product per 

15 SI unit. However, a SI unit can be associated with multiple products that 
define their own set of maintenance increments. As a result, a specific SI 
unit's complete maintenance definition is the union of all product and SI unit 
defined maintenance increments. 

If a product defines a specific time increment as maintenance, then all 

20 other products associated with the same SI unit inherit that specified time 

increment as maintenance also. Non pure points product associated includes a 
validation of the specified maintenance increments that ensures that no existing 
widgets of PI have been sold during the intersecting maintenance time 
increments. 

25 The maintenance increments defined in operation 1920 are accessible to 

the subsequent operations of non pure points product association because the 
subsequent operations interact with the maintenance increments. Preferably, 
the maintenance increments are defined using a dropdown time increment user 
object- The dropdown time increment user object displays all of the time 

30 increments for the PI being defined. To define the maintenance increments the 
user simply selects the time increment to define as a maintenance increment. 



PCT/USOO/10492 

57 

In operation 1930, the user may view unit allocation details. Products 
with a usage type whose contract unit allocation attribute, defined in operation 
655, is "type" are defined as floating over the product inventory's space 
dimension. A product with a floating space dimension is sold by the unit type 

5 and not the specific units that were selected for the association. Therefore, 
although specific units are still specified during the association process they 
only serve as bounds to the floating capability of the product inventory within 
the unit type. The unit allocation details provides a summary of the floating 
bounds, e.g., a list of units available to the product, within a unit type for the 

10 floating space products. The unit allocation details provide the user with the 
opportunity to confirm that the correct number of units within each unit type 
was selected for the association. The unit allocation details operation is purely 
an informational display, therefore no data modification is performed in this 
operation. 

15 In operation 1940, the user may define time allocation details for 

fractional products. Products with a usage type whose sales time unit 
attribute, defined in operation 610, is 'fraction' have no predefined time 
dimension. Therefore, the time dimension is defined during this operation. 
The product's usage type defines how many increments (fractions) need to be 

20 defined herein. This operation distributes the defined time increments into the 
various fractions. The fractions themselves can have both a fixed and a 
floating component- The fixed components will always be specified as a 
quantity of increments desired in each season. This guarantees that the owner 
will have rights to the specified quantity of time increments in the season 

25 although the specific increments within the season cannot be guaranteed. 

Suboperations 1942 and 1944 of operation 1940, define the time 
dimension for fractional products. In operation 1942, the user is presented 
with a plurality of fields presenting data associated with fractional products^ 
preferably including: the name of the product being associated, the sales time 

30 unit associated with the product's usage type, the sales increment associated 
with the product's usage type, the number of increments in the year that are 
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accounted for in a fraction definition as a fixed component, the number of 
increments in the year that are accounted for in a fraction definition as a 
floating component, the number of increments in the year that are accounted 
for in a fraction definition as either a fixed or floating component, the name of 

5 the fraction for the specified product/inventory association, the description of 
the fraction for the specified product/inventory association, the number of 
fixed increments that is defined for the specified fraction, the number of 
floating increments that is defined for the specified fraction, a color coded 
graphical representation of every increment in the year according to their 

10 season's color, the name of the specified season in the appropriate calendar, 
the number of floating increments in the specified season as defined for the 
specified fraction, the number of floating increments in the specified season 
defined for the other fractions, and the number of increments in the specified 
season that are not defined as either a fixed or floating increment in any 

15 fraction. 

The user then utilizes the information presented in operation 1942 to 
define the current fraction in operation 1944. In operation 1944, the user 
selects the name of the fraction that will be defined. The user then selects 
fi^om the color coded graphical representation of increments, the fixed 

20 increments that will be associated with the current product. Defining the fixed 
increments for the product causes any field effected by the definition to be 
updated. Accordingly, the floating increments for the fractional product are 
updated. If the user is satisfied with the fractional product defined the user 
may save the product. Figure 6b shows a table with four fractional products. 

25 For example, the time dimension for the fractional product "Fraction 1" 632, is 
fixed weeks 1-6 (634), four floating weeks during the High Season and three 
floating weeks during the Low Season (636). 

In operation 1750, the user may initialize the pricing and points 
attributes for the product. The Tool tracks and maintains three prices for each 

30 widget of product inventory; the drop price, price, and cost. The drop price is 
the minimum price at which the widget of product inventory can be sold. The 
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price is the actual price that the widget of product inventory should be sold 
for. The actual cost of the widget of product inventory is also tracked and 
maintained by the TooL 

The Tool also tracks and maintains a points value association for each 

5 widget of product inventory that is derived from a product usage type with a 
'sales points' flag of 'Y' defined in operation 630 of Figure 6. Otherwise, the 
user will not be required to initialize points. Generally, the points value 
attribute allows the system to sell the product inventory as the widget itself 
(space/time) or by a points specification where a specified points value is 

10 resolved into actual product inventory. 

The ability to specify an initial value for these pricing and points 
attributes during the association process provides the user with an efficient 
way to define product inventory. Although, the situation is probably rare that 
the initial pricing and points values specified are appropriate for all product 

15 inventory that will be generated from the association, the capability is provided 
by the system in case the user wants to take advantage of its existence. The 
pricing and points may also be defined in operations associated with the 
inventory management navigation module as discussed below. 

In operation 1960, the user may initialize inventory dates attributes. 

20 The Tool tracks and maintains two dates associated with each piece of product 
inventory (widget): the "inventory first date available for sale" ("IFDS") and 
the "inventory first use date" ("IFU") The IFDS is the first date that the piece 
of product inventory can be sold. The IFU similarly determines the first date 
that the piece of product inventory is available for use by a member or owner, 

25 In operation 1970, the user may initialize the business entities. The 

Tool tracks and maintains four business entity associations for each piece of 
product inventory. These four business entities are the seller, the association, 
the servicer, and the club. The seller determines the business entity that serves 
as the seller of the associated widget. The seller owns the accounts receivable 

30 ledger and the contract sales ledger. The accounts receivable ledger tracks 
revenues and expenses associated with a timeshare. The contract sales ledger 
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tracks contract revenues and expenses. The various ledgers discussed herein 
are, generally, accounting ledgers that are defined in an account administration 
module. The account administration module is not discussed in detail herein, 
however, one of ordinary skill in the art would be able to implement the 
5 accounting ledgers. The association determines the business entity that serves 
as the association for the widget. The association bills and collects the 
maintenance fees and owns the maintenance fee account receivables ledger. 
The maintenance fee accounts receivable ledger tracks maintenance fee 
receivables. The servicer determines the business entity that is associated with 

10 each widget as its servicer. The servicer bills and collects reservations fees 

and owns the mispellaneous member services accounts receivable and accounts 
payable ledgers. The accounts payable ledger tracks members account 
balances. The club determines the business entity that manages the points 
activity for the widget. The club owns the points audit ledger and the points 

15 management subsidiary ledger. 

Figure 20 illustrates the exemplary operations involved in a "pure 
points" product association. In operation 2010, the user defines the point 
allotments for the pure points product being associated. A pure points product 
can only be associated to resort SI entities. As a result, the resort must define 

20 the total points it will obligate to timeshare sales, the amount of those total 
points that must be set aside for maintenance obligations, and the schedule of 
how many points become available at what time. The total points for the 
resort defines the upper bound for the defined allotments. At any point in 
time, the actual total points available for timeshare sales is determined by the 

25 vahd allotments less the maintenance points, rather than the total points less 
the maintenance points. 

In operation 2010, the user is presented with a plurality of fields 
presenting data associated with allotments, preferably including: the total 
number of points that the resort has defined for sale, the total number of points 

30 that the resort has set aside as maintenance points, the difference between the 
total points and maintenance points, /.e., the number of points available for 



wo 00/63794 PCT/USOO/10492 

61 

sale, the name of the specified allotment, the amount of points that will be 
brought on-line as part of the allotment, and the date that the specified 
allotment becomes available for use. The user may then add, delete or modify 
the existing allotments, 
5 In operation 2020, the user may define the pricing of the pure points 

product being associated. Pure points products are sold strictly as points. The 
owner specifies the number of points that is desired in some combination of 
valid points packages. The exact combination of points packages used to meet 
the desired points value will directly affect how the sale is priced. These 
10 points packages are set up with the pure points product during the product 
definition process, as described above in regard to operations 835 - 845 of 
Figure 8. However, the pure points product cannot be priced until an 
association is made to a resort SI entity. 

Similar to the pricing mechanics for inventory-backed products, /.e., 
15 non pure points products, the Tool tracks and maintains three prices for each 
points package defined for the product: the drop price, price, and cost. The 
drop price is the minimum price that the points package can be sold. The price 
is the actual price that the points package should be sold for. The actual cost 
of the points package is also tracked and maintained by the system. 
20 In operation 2030, the user may define the business entities related to 

the product inventory being associated. The Tool tracks and maintains four 
business entity associations for each piece of product inventory (widget). 
These four business entities are the seller, the association, the servicer, and the 
club. The seller determines the business entity that serves as the seller of the 
25 associated widget. The seller owns the accounts receivable ledger and the 
contract sales ledger. The association determines the business entity that 
serves as the association for the widget. The association bills and collects the 
maintenance fees and owns the maintenance fee account receivables ledger. 
The servicer determines the business entity that is associated with each widget 
30 its servicer. The servicer bills and collects reservations fees and owns the 
miscellaneous member services accounts receivable and accounts payable 
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ledgers. The club determines the business entity that manages the points 
activity for the widget. The club owns the points audit ledger and the points 
management subsidiary ledger. 



5 Contract Inventory Selection — Sale 

When a timeshare widget from PI is purchased, the user utilizes the 
contract inventory selection operations illustrated in Figure 21 to verify the SI 
availability of the widget that is being purchased. Note, "contract" as used 
herein refers to the rights in a widget that a timeshare owner has purchased. 

10 The contract inventory selection operations are preferably available to the user 
when a new contract is created so that inventory availability is confirmed as 
soon as possible. Generally, contract inventory selection includes the 
following operations: entering search criteria, obtaining a list of inventory that 
matches the search criteria, selecting items to apply to the contract, and 

15 removing the selected items from general sales availability. The overall 
contracting process is performed outside the Tool. 

Figure 21 illustrates the exemplary operations involved in contract 
inventory selection. Inventory selection is preferably defined by the user using 
drop-down data windows. In operation 2102, the user selects the resort that 

20 the contract owner is searching inventory for. In operation 2104, the user 
selects the product that the contract owner is searching inventory for. The 
resort and product selection operations 2102 and 2104 are preferably 
mandatory. The following operations 2106- 2120 further define the search 
criteria. However, operations 2106-2120 are preferably optional. 

25 In operations 2106 and 2108, the user may select the phase that the 

contract owner is searching inventory for. In operations 2110 and 21 12, the 
user may select the building that the contract owner is searching inventory for. 
In operations 2114 and 2116, the user may select the unit that the contract 
owner is searching inventory for. And, in operations 2118 and 2120, the user„ 

30 may select the week that the contract owner is searching inventory for. 
Operations 2102 - 2120, define the search criteria. 
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In operation 2122, the Tool searches for inventory based on the search 
criteria. The inventory matching the search criteria is displayed in operation 
2124. An exemplary window illustrating the results of a search is provided in 
Figure 21a. Numerous attributes associated with the inventory are displayed, 
5 including: the resort 2124a, the phase 2124b, the building 2124c, the unit 
2124d, the increment 2124e, the frequency 2124f, the availability 2124g, the 
owner first use date 2124h, and the quantity for purchase 2124i. 

In operation 2126, the user selects the inventory to associate with the 
contract. Referring to Figure 21a, the selected inventory is "ProductX" 

10 (2126a) which is a "fixed/fixed" product including "unit 201 /week 1" at 

"Resl ." After selecting the inventory in operation 2126, the user may define 
an add-on membership in operations 2128 and 2130. The add-on membership 
operations 2128 and 2130 are substantially similar to operations 900 - 960a 
described above In addition, the user may add a points package in operation 

15 2132. Adding a points package includes selecting a points package to add in 
operation 2134 and selecting a points purchase package quantity in operation 
2136. The quantity refers to more than one points package. For example, if 
two 1000 points packages are selected, then 2000 total points are added. 

In operation 2138, the user defines the owner first use date which is ihe 

20 first date the owner can use the widget. In operation 2140, the user defines 
the quantity for purchase. Finally, in operation 2144, the user may release the 
inventory to the contract. If the inventory is released, the inventory released is 
no longer available sales inventory. 

The contract inventory selection operations discussed above are subject 

25 to various selling rules and selling preference that will be applied whenever a 
use attempts to search for widgets based on specified inventory. Selling rules 
are determine what inventory can be sold. Fop example, a rule selling rule can 
require that for every five 1 bedrooms that are sold a three bedroom must be 
sold. Accordingly, if the sixth 1 bedroom is searched for before the first three 

30 bedroom is sold, then the search will not return a match. Selling preferences is 
the order that the inventory is presented for selection. For example, if one 
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match is from a new phase and four matches are from an older phase, then the 
older phase matches may be presented first in order to sell out the old phase 
before beginning to sell the new phase. 



5 Inventory Management Navigation Module 

The inventory management navigation module (hereinafter "IMNM") is 
a central launching point for the operations discussed herein. The IMNM 
provides the user with three views of the various inventory systems: HI, SI 
and PL The HI view will allow the user to see all of the defined HI entities, 

10 e.g., resort, cluster, room type, and room, in a hierarchical treeview display. 
Likewise, the SI view will allow the user to view all of the defined SI entities, 
e.g., resort, unit type, and unit, in a hierarchical treeview display. Finally, the 
product view will list ail of the defined products in the system and their 
product to SI associations in a treeview. The three views provide the user 

15 with all requisite views of the inventory systems irt an efficient and convenient 
manner. The IMNM also supports all fiinctionality of defining and maintaining 
products, HI, SI and PI as described herein. The user will able to view any of 
the HI, SI or PI ft^om the IMNM while modifying any of the HI, SI or PI at the 
same time. 

20 The IMNM includes three main menu selections: inventory 

management, product, and inventory. The inventory management menu allows 
the user to select the exact view of inventory that is desired or toggle through 
the various views to determine the best view for the current action. In 
addition, all other operations of the Tool may be accessed through this menu. 

25 The product menu allows the user to define the various products that are 
supported by the Tool as described above with regard to Figures 3-9. The 
product menu also allows the user to initiate the product to SI association 
operations as described above with regard to Figures 18-20. Recall, product 
to SI association creates the PI widgets that are sold and hence required to 

30 support timeshare functionality. The inventory menu allows the user to 
interact with the various inventory entities - HI, SI and PL Finally, the 
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inventory menu also allows the user to initiate blocking and overbooking which 

are discussed in more detail below. 

The following windows illustrate the preferable implementation of the 

three main IMNM menu selections. In addition, the windows shown in Figures 
5 22, and 22a - 22g exemplify the preferable GUI implementation of the various 

operations described herein and illustrate the look and feel of the Tool. Of 

course other GUI implementations are possible. 

Figure 22, illustrates the main menu window for the Tool and the 

application. Many of the operations and resultant inventories discussed herein 
10 are used by the various modules of the application shown in the main menu 

screen. The inventory management icon 2210 launches the IMNM. Figures 

22a - 22g are exemplary window screen shots that are accessible through the 

IMNM. Figure 22a is the toolbar that is first viewed when the IMNM is 

accessed. The toolbar includes an inventory management drop down menu 
15 2210a, a product drop down menu 2220a, an inventory drop down menu 

2230a, a worklist drop down window 2240a and a help drop down menu 

2250a. 

The contents of the inventory management drop down menu 2210a are 
illustrated in Figure 22b. Many of the various operations discussed herein are 

20 accessible from the inventory drop down menu. For example, the HI 2210b, SI 
2220b, PI 2230b, resort calendar 2240b and resolved usage rights 2250b 
operations, amongst the others shown in Figure 22b, are all accessible from the 
inventory management drop down data menu 2210a. 

Figure 22c, illustrates the window that is presented if the HI link 2210b 

25 is selected in the inventory management drop down menu 2210a. The HI 
window includes a list of the defined hotel inventory 2210c. The user may 
select one of the defined HI at which time associated attributes 2220c are also 
displayed. The associated attributes includes the code of the resort 2230c and 
the name of the resort 2240c, amongst other attributes, as defined in main 

30 operations 1300a - 1330g discussed in conjunction with Figure 13. In 
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addition, the HI window includes various operational links 2250c along the top 
of the window. 

Figure 22d, illustrates the window that is presented if the SI link 2220b 
is selected in the inventory management drop down menu 2210a. The SI 

5 window includes a list of the defined sales inventory 2210d. The user may 
select one of the defined SI at which time associated attributes 2220d, such as 
resort information 223 Od, are also displayed. Like the Hi window, various 
operational links 2240d are provided along the top of the window. 

Figure 22e, illustrates the window that is presented if the PI link 2230b 

10 is selected in the inventory management drop down menu 2210a. The PI 

window includes a list of the defined product inventory 2210e. The user may 
select one of the defined PI at which time associated attributes 2220e, such as 
the usage type 2230e, are also displayed. Like the HI and SI window, various 
operational links 2240e are provided along the top of the window, including a 

15 link to the resort season calendar, and a link to any defined product calendars. 

Figure 22f illustrates the product drop down menu 2220a. The product 
drop menu 2220a includes a link 221 Of to the timeshare product definition 
main operations 300 - 360, a link 2220f to the miscellaneous product setup 
operations (discussed directly below - need to discuss), a link 223 Of to the 

20 product calendar operations, and a link 2240 to the product inventory 
association discussed with regard to Figures 18-20. 

Miscellaneous products are products that do not fit into space/time or 
points category of products. However, miscellaneous products can be defined 
for sale and inventory control by quantity of products in existence. For 

25 example, golf club sets or stand-alone gym memberships are potential 
miscellaneous products. 

Figure 22g illustrates the inventory drop down menu 2230a. The 
inventory drop menu 2230a includes numerous links to various operations, 
especially the hotel and sales inventory definition operations discussed in 

30 conjunction with Figures 10 - 17. The links to operations accessible through 
the inventory menu drop down menu 2210g include; a link 2210g to the resort 
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definition operations 1300 - 1372, a link 2220g to the unit type definition 
operations 1610 - 1660, and a link 223 Og to the unit definition operations 1700 
- 1738. 

5 Resolved Usage Rights 

An owner of a timeshare widget is granted rights to specific 
intersections of time and space depending upon the usage rights of the specific 
widget that was purchased. As noted above in conjunction with the contract 
inventory selection operations, after a timeshare widget is purchased, the 

10 owner has a "contract." The particular widget purchased is associated with a 
contract in the contract inventory selection operations. Every widget that is 
purchased includes usage rights, defined in operations 700 - 799 that are 
defined during the product definition operations, as discussed above along with 
Figures 3-9. Usage rights generally define a set of attributes including when 

15 an owner can make a reservation, when an owner can use the timeshare 

inventory, and the type of accommodation that is provided. The attributes are 
defined in terms of expressions that serve as a general rule for the specified 
product- However, the expressions used to define the attributes will resolve to 
different values for each piece of sales inventory that is used to create product 

20 inventory through the product to SI association operations discussed above 
along with Figures 18-20. Specifically, the reservation and usage window 
attributes, defined in operations 720-735, of a usage right will change 
according to the implied dates of the specific product inventory widget's time 
increment, i.e., weekl. 

25 The generation of resolved usage rights fi-om the usage rights provides 

the owner with the ability to actually use their purchases. However, the 
discrete operation of resolving usage rights is sometimes not sufficient for the 
owner to gain access to all of his timeshare rights. This is especially true for 
owners of points-based products. For these points owners, other points 

30 accounting sub-processes are executed prior to their rights becoming effective 
and usable. In particular, the operation of resolving usage rights must also 
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execute some or all of the following points accounting tasks if the associated 
product inventory being resolved is points based: initialize club points, 
allocate points for new owners or members, allocate incentive points, allocate 
points for existing owners or members, expire points, and create extended 

5 exchange transactions. Furthermore, to ensure the accuracy of the various 
points accounts, the following processes will also be performed: usage period 
end adjustment and cancel contract points. 

The usage rights resolution (hereinafter "URR") operation will be 
executed for all "active" contracts, /.e., for all existing timeshare widgets that 

10 have been purchased and are still active, and contracts that have been canceled 
after the last time the operation was executed. Furthermore, "active" contracts 
can be classified into two types, those that are existing (reached the requisite 
status prior to the last execution of the URR operation) and those that are new 
(reached the requisite status after the last time the URR operation was 

15 executed). Thus, on a scheduled recurring basis, the URR operation will 
execute and query the Tool for all appropriate contracts. All qualifying 
contracts will be processed in the URR operation. The URR operation 
executes for each qualifying contract individually and the set of qualifying 
contracts will also be processed together. Depending upon the status of each 

20 individual contract, one or more of the sub-processes listed above will be 
executed. In addition, the user may initiate the URR operation as an 
immediate action from a manual triggering mechanism. 

Figure 23 illustrates the preferably operations involved in the URR 
operation. The URR operation determines all contracts that have attained the 

25 required user defined contract status and execute the required operations to 
provide the contract owners with rights to use their purchased timeshare 
inventory. For each contract, the URR operation executes the following 
operations as part of the overall URR operation. 

In operation 2305, usage rights are resolved. This operation resolves 

30 the usage rights specified during the product definition operations to resolved 
usage rights that will afford the owners with the ability to use the purchased 
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timeshare inventory. The Tool will determine the set of product inventory 
widgets associated to the qualifying contract. For each product inventory 
widget, its set of usage rights will be resolved to a corresponding set of 
resolved usage rights ("RUR"). The RUR will have a logical relationship 

5 amongst themselves as determined by their relative order and the logical 
operators of the underlying usage rights, defined in operation 755. 

Each usage right will resolve to potentially one or more RUR. For 
example, non-contiguous seasons and fractions may resolve to a set of RURs 
instead of a single RUR. The many usage rights that are resolved out of a 

10 single usage right record have an implied logical relationship to the set as a 

whole. The exact logical relationship will depend upon the product inventory's 
associated usage type attributes. Specifically, the sales time allocation, defined 
in operation 625, and contract time allocation, defined in operation 660, 
attributes will determine whether the one to many RUR have an implied AND 

15 or OR logic amongst the entire set. The table illustrated in Figure 23a, 
illustrates the different possibilities. 

The row referred to by reference numeral 2310a represents a product 
inventory widget from a fixed time product. The date keywords "fixed or 
floating" and "increment," defined by the sales time allocation operation 625 

20 and contract time allocation 660 respectively, will always resolve to a single 
date so all resolutions will be one to one. 

The row referred to by reference numeral 2320a is a product inventory 
widget from a floating time product. The date keywords "fixed or floating" 
and "season," defined by the sales time allocation operation 625 and contract 

25 time allocation 660 respectively, will potentially return a set of dates, one for 
each non-contiguous range of the increments that comprise the season. As a 
result, the owner has rights to use an increment of duration "n" days as defined 
by its time unit anywhere within the set of date ranges that were resolved from 
the season's contiguous time increments. Thus, the logical relationship is an 

30 OR 
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The row referred to by reference numeral 2330a, is a product inventory 
widget from a fractional product. Similar to the floating time product example 
above, the date keywords "fraction" and "increment" will potentially return a 
set of dates, one for each contiguous set of fixed time increments that 

5 comprise the fraction and one for each floating increment that comprise the 
fraction. Fractional product owners, however, have a right to use the entire 
fraction and not just a single increment bounded by the fraction definitions. As 
a result, the owner will have rights to all of the resolved usage rights records 
in this case. Thus, the logical relationship is an AND between all fixed 

10 increment resolutions and the set of floating increment resolutions. However, 
the set of floating increment resolutions will have an implied OR relationship in 
the case of noncontiguous season definitions. 

The row referred to by reference numeral 2340a, is a pure points 
product- Pure points usage rights imply usage across all resorts in the 

15 organization. However, the RURs can only be used at one of the many resorts 
that may exist within an organization. The one resort that the right is used 
against is completely at the discretion of the owner. All other cases detailed 
above in the table of Figure 23 a are preferably invalid combinations and are not 
defined within the Tool. 

20 All resolved usage rights or set of resolved usage rights will maintain 

the logical relationship, defined in operation 755, that exists between its 
spawning usage rights records. For example, consider two usage rights (URl, 
UR2) where the logical relationship is "URl AND UR2." If URl resolves to 
"RURl OR RUR2" because the product inventory is fi^om a floating product; 

25 UR2 resolves to "RUR3 OR RUR4." Then the final logical expression of the 
entire set of resolved usage rights is (RURl OR RUR2) AND (RUR3 OR 
RUR4). A RUR Boolean expander algorithm will then simplify this set of 
resolved usage rights records to a more intuitive representation of sets of 
mutually exclusive records. For the above example, the simplified expression 

30 is: (RURl AND RUR3) OR (RURl AND RUR4) OR (RUR2 AND RUR3) OR 
(RUR2 AND RUR4) 
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In operation 2310, the RUR operation initializes club points. A club is 
a group of affiliated resorts that provide the ability for their owners to 
exchange with one anther. Club points are essentially the same as the "points*' 
discussed herein. The club point initialization operation allocates total points 
5 available to the club for the defined usage period and records them in the user- 
defined accounts in the points audit ledger ("PAL"). The PAL keeps track of 
the use of club points in a debit credit fashion. Entries are posted to: Debit the 
specified "asset" account and Credit the specified "reserves" account. The 
"asset" account, which does not carry a status, is created by the Tool when the 
10 ledger is set up in the member services module; therefore, the account will 

never become inactive. Note, the member services module is not discussed in 
detail herein. The "reserves" account, however, is user-defined and carries a 
status. If the "reserves" account associated with the club is inactive, then an 
error will need to be logged to the scheduler log files and the entire RUR 
15 operation will be rolled back to its previous states. Likewise, if a "reserves" 
account is not associated with the club, then an error will be logged to the 
scheduler log files and the entire RUR operation for the current contract will 
be rolled back to its previous states. 

In operation 2315, the RUR operation allocates points to new owners or 
20 members. As new sales occur, points need to be allocated to their 

owner/member accounts in the points management subsidiary ledger ("PMSL") 
that is defined in the member services module and tracks each members 
available points. New members/owners are defined as any new purchasers 
since the last allocation that have usage rights within the defined usage period. 
25 The allocation process allocates points to the appropriate accounts in the 

PMSL and the liability and reserves accounts in the PAL. Entries are posted 
to: allocate points to each new owner/member account in the PMSL, credit a 
designated "liability" account in the PAL for usage period owner/member 
"regular points" liability, debit a designated "reserves" account for 
30 owner/member usage period liability. The "liability" and "reserves" accounts 
are user-defined and carry a status. If the account(s) are inactive, then an 
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error will need to be logged to the scheduler log files and the entire RUR 
operation for the current contract will be rolled back to its previous states. If 
a "reserves" and/or "liability" account is not associated with the club, then an 
error will need to be logged to the scheduler log files and the entire RUR 
5 allocation process for the current contract will be rolled back to its previous 
states. 

In operation 2320, the RUR operation allocates incentive points. 
Incentive points are given to members as an incentive to purchase a timeshare. 
The following entries are posted: allocate points to the owner/member points 

10 account in the PMSL; credit a designated "liability" account in the PAL for 
usage period owner/member liability; and debit a designated "incentive 
reserves" account. The "liability" and "incentive reserves" accounts are 
user-defined and carry a status. If the account(s) are inactive, then an error 
will need to be logged to the scheduler log files and the entire RUR operation 

15 for the current contract will be rolled back to its previous states. If an 

"incentive reserves" and/or "liability" account is not associated with the club, 
then an error will need to be logged to the scheduler log files and the entire 
RUR operation for the current contract will be rolled back to its previous 
states. 

20 In operation 2325, the RUR operation allocates points to existing 

owners or members. The Tool will determine all contracts in the Tool that 
have a points value associated with them. These qualifying contracts will be 
those with product inventory that have associated resolved usage rights with 
points accommodations. The allocation process allocates points to the 

25 appropriate accounts in the points management subsidiary ledger (PMSL) and 
the liability and reserves accounts in the PAL. Entries are posted to: credit 
each owner/member points account in the PMSL; credit a designated "liability" 
account in the PAL for usage period owner/member "regular points" liability; 
debit a designated "reserves" account for owner/member usage period liability^ 

30 The "liability" and "reserves" accounts are user-defined and carry a status. If 
the account(s) are inactive, then an error will need to be logged to the 
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scheduler log files and the component existing owner/member allocation 
process for the current contract will be rolled back to its previous states. If a 
"reserves" and/or "liability" account is not associated with the club, then an 
error will need to be logged to the scheduler log files and the component 
5 existing owner/member allocation process for the current contract will be 
rolled back to its previous states. 

In operation 2330, the RUR executes the expires points operation. The 
expire points operation is used periodically to process transactions, which 
adjust accounts for points that have expired. When points are allocated, they 

10 are given an effective date and expiration date, which define the period of time 
for which they are valid and must be used. The following entries are posted 
for this process: debit each owner/member or exchange company account in 
the PMSL by the number of expired points as of the date the process runs; 
debit the appropriate "Uability" accounts; and credit the "asset" account used 

15 to track total points for the specified usage period in the, PAL. When the 
operation runs, each owner/member or exchange company account in the 
PMSL will have a transaction posted to decrease it by the number of expired 
points. Points will be reversed with an "Expired" transaction type based upon 
the expiration date entered when the transaction occurred to increase the 

20 account through allocation, rent, borrow, bank, etc. The "asset" account, 
which does not carry a status, is created by the system when the ledger is set 
up; therefore, the account will never become inactive. The "liability" account, 
however, is user-defined and carries a status. If the "liability" account 
associated with the club is inactive, then an error will be logged to the 

25 scheduler log files and the component expire points process will be rolled back 
to its previous state. If a "liability" account is not associated with the club, 
then an error will be logged to the scheduler log files and the component 
expire points process will be rolled back to its previous state. 

In operation 2335, the RUR operations adjusts the usage period end. 

30 At the end of each usage period specified for the club defined in the PAL, the 
PAL account balances must be adjusted to close the period. The following 
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entries are posted to: debit the points "reserves" accounts to zero the points 
balance for remaining "unused" or "unallocated" points for the usage period; 
and credit the points "asset" account that tracks the total points available 
throughout the use period for the amount of the current debit balance. The 
5 "asset" account, which does not carry a status, is created by the system when 
the ledger is set up; therefore, the account will never become inactive. The 
"reserves" account, however, is user-defined and carries a status. If the 
"reserves" account associated with the club is inactive, then an error will be 
logged to the scheduler log files and the component usage period end 

10 adjustment process will be rolled back to its previous state. If a "reserves" 
account is not associated with the club, then an error will be logged to the 
scheduler log files and the component usage period end adjustment process 
will be rolled back to its previous state. 

In operation 2340, the RUR operation executes the cancel contract 

15 points operation. The system will determine the set of contracts that have 
been canceled since the last execution of the process. This set of freshly 
canceled contracts will serve as the driving factor of the cancel points 
component process. When a contract is canceled, all point transactions in the 
owner/member account for that contract with the exception of a "Rent" 

20 transaction needs to be reversed. The transactions in the PAL that are tied to 
that contract also needs to be reversed. 

In operation 2345, the RUR operation creates extended exchange 
transactions. Extended exchange transactions refer to a two phase expiration 
of points. At the end of each usage period, a member's points expire. 

25 However, for some organizations these points don't truly expire completely 
from the system. The member's expiring points are transferred from allocated 
points to extended usage points. Extended usage points have a life span 
defined by a business policy. They are valid for the period defined by the 
business policy, starting on the date the allocated points expired. These 

30 extended usage type of points may have restricted usage capabilities depending 
upon how the business policies have been defined. This component process is 
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probably triggered by the component expire points process to ensure that all 
extended usage occurrences are properly handled by the system. 

The Tool also allows split definitions. A split definition allows a 
member to change their resolved usage rights into many resolved usage rights 

5 with different check-in-days and length-of-stays. For example, a float/float 
widget based on a "week" time unit might be divided into two float/float 
widgets with the total time for both widgets equaling one "week." A split is 
defined at the resort and time increment association. For each association, the 
user may define many split types, with each split type having a list of valid 

10 check-in-days and length-of-stays that total the time increment. 

Hotel Inventory Control and Reservation Module 
Hotel inventory control manages the usage of hotel inventory for 
purposes of reservations and inventory blocks. As discussed above with regard 

15 to Figures 10 - 17, HI is setup and maintained at four levels: resort, cluster, 
room type and room. A resort is defined in the Tool as the physical location of 
the building or buildings that house the physical inventory available for rent. A 
cluster is defined in the Tool as a grouping of room types based on similar 
pricing. A room type is defined in the Tool as a grouping of rooms with 

20 similar attributes. For example, all two bedroom rooms or all ocean view 

rooms may be grouped together as a room type. Finally, a room is defined in 
the Tool as the physical piece of inventory available for rent. 

The Tool includes a reservation system that allows an agent to confirm 
reservations at all levels of defined inventory. Reservations may be confirmed 

25 at four different levels: run of house ("ROH"), run of cluster ("ROC"), run of 
type ("ROT") or room. A ROH reservation means that a guest is given 
confirmation that they will have a room in the resort available at check-in time. 
The guest does not require any special room attributes, e,g.^ room type, or any 
special price attributes, e.g., cluster, A ROC reservation means that a guest is 

30 given a confirmation that they will have a room in an agreed cluster, i.e., 
pricing group, at check-in. The guest does not require any special room 
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attributes. A ROT reservation means that a guest is given confirmation that 
they will have a room in an agreed upon room type at check-in. Finally, a 
room reservation means a guest is given confirmation that they will have the 
requested room at check-in. The reservation agent typically makes 

5 reservations at the highest level (ROH) in order to try and accommodate future 
customers requesting reservations at a more specific level such as ROT. This 
strategy maximizes hotel revenue and customer satisfaction by not arbitrarily 
assigning customers to rooms with specific attributes such as ocean view when 
they do not desire the view. 

10 The hotel inventory control and reservations module provides 

guaranteed sustained availability. Sustained availability is the number of 
consecutive nights that a particular room is available. Sustained availability is 
an improvement over other reservation systems that only provide daily 
availability. The following example fiirther explains sustained availability. 

15 Figure 24 illustrates an exemplary availability chart for rooms 101, 102 and 
103 for three nights January 1, 2 and 4. A "Y" signifies that the room is 
available for the particular date and a "N" signifies that the room is not 
available for the particular date. Daily availability for a requested three night 
stay, IBR (one bedroom) room type, starting January 1 is two Meaning, on 

20 any given night there are at least two rooms available. However, the sustained 
availability for the same request is zero because a guest will not be able to stay 
in the same room for all three nights. Preferably, sustained availability is 
implemented using a recursive technique. 

The hotel inventory control and reservation module also provides for 

25 the setup and maintenance of overbooking and the setup and maintenance of 
blocks. Overbooking allows the reservation agent to make more reservations 
than there are rooms available to fiilfiU guest requests. Overbooking amounts 
are defined at all levels except the actual rooms. Overbooking relies on 
cancellations so that there are not more guests than rooms available. 

30 Figure 25 illustrates the exemplary operations involved in defining 

overbooking amounts. In operation 2510, operation 2520, and operation 
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2530, the user selects the resort, cluster and room type respectively to define 
overbooking amounts for. In operation 2540, the user selects the beginning 
date of a range of time that the overbooking limit is going to be assigned to. 
In operation 2550, the user selects the end date for the range of time that the 

5 overbooking limit is going to be assigned to. In operation 2560, the user sets 
the overbooking limit for the range specified. Finally, in operation 2570 the 
user may select to exclude particular dates from the range for which the 
overbooking limit will not be applied. 

The tables presented in Figures 25a, 25b, 25c, 25d and 25e illustrate 

10 how the overbooking limits affect availability. Figure 25a illustrates the 

current availability for an exemplary resort "R," with two clusters "CLl" and 
"CL2," with each cluster having two room types "RTl" and "RT2." ROH 
availability is illustrated in the Figures as a row with only the Resort defined, 
e.^., the row with reference number 2510a. ROC availability is illustrated in 

15 the Figures as a row with the resort and cluster defined, e.g., the row with 

reference number 2520a. The ROT availability is illustrated in the Figures as a 
row with the resort, cluster and room type defined, e,g,, the row with 
reference number 2530a. All availability numbers rolKup to the resort level. 
For example, if a reservation is made at the ROT level, then the ROT, ROC 

20 and ROH availability numbers decrement by 1 . 

The following three scenarios refer to Figures 25a - 25e to illustrate the 
effect of overbooking on availability. Referring to Figure 25a, in scenario one, 
when a reservation is requested for RT2, then RT2 has 1 available, C 1 has 1 
available, and R has two available therefore no overbooking rules are required 

25 because there is availability at all levels. Accordingly, RT2 is decremented, Cl 
is decremented and R is decremented. The resulting availability is illustrated in 
Figure 2c- 

In scenario two, a second reservation is requested for RT2. RT2 is no 
longer available because it was reserved in scenario one. Accordingly, 
30 overbooking for RT2 is checked. Referring to Figure 2b, RT2 may be 

overbooked by 2. Therefore, the availability for Cl is checked. Cl is not 
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available. Referring to Figure 2b, CI may be overbooked by 2. Therefore, the 
availability for R is checked. R has availability, therefore, the reservation for 
RT2 is taken and RT2, Cl and R are decremented. The resulting availability is 
illustrated in Figure 25d. 
5 In scenario three, a reservation is requested for RT3. Referring to 

Figure 25b, RT3 is not available. Therefore, referring to Figure 25b, the 
overbooking limit for RT3 is checked. RT3 may be overbooked by 2, 
therefore the availability of C2 is checked. Referring to Figure 25d, C2 is not 
available, therefore the overbooking limit for C2 is checked. C2 cannot be 

10 overbooked so request cannot be granted unless a supervisor override is 
granted. If supervisor override is granted, then the availability for R is 
checked Referring to Figure 25d, R is not available, therefore check the 
overbooking limit for R. R can be overbooked, therefore take the reservation 
and decrement R, C2 and RT3 . The resulting availability is illustrated in 

15 Figure 25e. All reservations at this point will require supervisor override 
because the resort limit for overbooking is set to 1 which was used. 

Blocking removes inventory from general availability into a special 
blocked availability. The blocking functionality is primarily used to guarantee 
availability to particular guests such as timeshare owners, conferences and 

20 marketing promotions. Blocking may also be used to restrict certain pieces of 
inventory from being used by anyone if, for example, the piece of inventory is 
scheduled for remodeling. Blocks are definable at any reservation level, 
including ROH, ROC, ROT and room, 

A block includes a block definition and the assigned inventory. The 

25 block definition defines the resort the block is defined at, a unique block code 
for the resort, a description and block expiration information. Inventory can 
be assigned at any level a reservation can be made, ROH, ROC, ROT, or room 
level. Each assignment of inventory will determine if the block will contain 
sustained or daily availability and the amount of inventory to block. The actual 

30 amount of inventory to be blocked depends on a block number, an authorize 
number, and a forecast number entered by the user at inventory is assigned to 
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the block. The block number is the actual amount of inventory to remove from 
general availability. The authorize number is the maximum number of 
reservations that can be reserved against the block. The forecast number is a 
best guess entered by the user as to what will be actually used. 

5 Figure 26 illustrates an exemplary window implementation for assigning 

inventory to a block. The window includes the following drop down 
datawindow ("DDDW") fields utilized by the user to assign inventory to a 
block: "Block Code" 2610, "From Date" 2615, "To Date" 2620, "Block" 
2625, "Authorize" 2630, "Forecast" 2635, "Resort" 2640, "Cluster" 2645, 

10 "Room Type" 2650, and "Room" 2655. In addition, the window includes a 
sustained type radial button 2660, a daily radial button 2665 and an expiration 
display field 2670. 

The block code field 2615 uniquely identifies a particular block. The 
expiration date field 2670 displays the expiration date for the block. The from 

15 date field 2620 allows the user to define the date fi-om when the inventory in a 
block is taken out of availability. The to date field 2625 allows the user to 
define the date when the inventory assigned to a block will be released to 
availability. The block field 2625 allows the user to define the number of 
pieces of inventory which will make up the block at a specific level in the 

20 hierarchy, e.g., two rooms or two clusters. The authorize field 2630 allows 
the user to define the number of pieces of inventory to assign to the block. 
The forecast field 2635 allows the user to define the number of pieces of 
inventory that the user believes will actually be used from the block. The 
sustained button 2660 allows the user to define the block as a sustained 

25 availability block. The daily button 2665 allows the user to define the block as 
a daily availability block. 

The resort field 2640 allows the user to select the resort to assign to the 
block. The cluster field 2645 allows the user to select the cluster to assign to 
the block. The room type field 2650 allow the user to select the room type to 

30 assign to the block. And, the room field 2665 allows the user to select the 
room to assign to the block. 
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Reservations 

Figure 27 illustrates the exemplary operations associated with 
processing a call from a member prior to making a reservation for a timeshare. 
After a member calls the resort or agent servicing a resort, the agent obtains 
5 various identifying parameters from the member in operation 2710. The 
identifying parameters include: a personal identification such as a social 
security number, passport numbers, etc; property or membership 
identification, a club defined identification, or the members last name. From 
the identifying parameter, the agent is presented with information about the 
10 member including: whether the members has any outstanding account balances, 
whether the member is a current or active member. In addition, clubs may also 
have special "current" rules that are checked. If the member is a current or 
active member than the member may make a reservation is operation 2720. 
Additionally, the member may exercise remaining usage rights or extend 
15 exchange options, settle any financial obligations, update contact information, 
inquiry about their membership, view points information and log complaints. 

Referring to Figure 27a, if the member seeks to make a reservation, 
then the agent determines if the members seeks to make a fixed time 
reservation, a floating time reservation or a points reservation, in operations 
20 2702a, 2704a and 2706a. 

If the member seeks to make a fixed time reservation, then operations 
2708a - 2728a are performed. In operation 2708a, the member specifies a time 
for the reservation. In operation 2710a, the agent searches for the specifies 
time. If the time is not available, then the member may request a new time. 
25 If the time is available, then payment processing is initiates in operation 

2714a. In operation 2716a, the Tool determines if the member's financial 
obligations are resolved. If not, then the reservation operation is terminated in 
operation 2718a. If the member is good financial standing, then the inventory 
according to the time selected is decremented in operation 2720a. In operation 
30 2722a, the agent books the reservation. In operation 2724a, the agent gathers 
any additional member information that may be required or desired. In 
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operation 2728a, the members usage rights are updated according to the 
reservation made. 

Referring to Figure 27b and 27c, if the member seeks to make a floating 
reservation, then the member make a request in operation 2710c. If the 

5 member chooses a single date in operation 2702c, then the Tool searches for 
the date requested according to the resolved usage rights for the member in 
operation 2704c If the request is not available, then the agent may check 
overbooking limits in operation 2740c. If overbooking is not available or the 
supervisor chooses not to override the overbooking limits in operation 2750c, 

10 then the member may make another request in operation 2702c. If, in 

operation 2702c, the user requested a date range, then the tool searches for the 
date range requested according to the resolved usage rights for the member in 
operation 2714c. If the request is not available, then the agent may check 
overbooking or a supervisor may override overbooking limits. If the request is 

15 available, the member is presented with a list of options to choose from in 
operation 2718c. 

If either the date request from operation 2702c or an option in 2720c is 
available or selected, then hotel availability is confirmed in operation 2712c. 
In operation 2722c, the Tool determines whether the member passed the rules. 

20 If the member did not pass, then the agent or supervisor may override the rules 
in operation 2724c. If the rules are not overridden, then the agent may not 
make a reservation and the operation is ended. 

In operation 2728c, the Tool determines if there is a transaction fee 
associated with the reservation. If there is, then the agent may override the fee 

25 in operation 2730c. Otherwise, the member must pay the fee in operation 

2732c. In operation 2734c, the Tool determines if there is a process payment 
associated with the reservation. If there is a process payment, then payment 
processing is initiated in operation 2736c. In operation 2738c, the Tool 
determines whether the member resolved any outstanding payment obligations. 

30 If not, then the availability is released and any payments corresponding to the 
reservation are reversed in operation 2740c. 
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If the customer did resolve any financial obligations or there was not a 
process payment, then the Tool process the delinquency policy in operation 
2742c. If the delinquency process fails, then the member is asked to submit 
payment in operation 2746c, If the user does not submits a payment, then the 
5 delinquency policy hits a fatal level and the availability is released and the any 
payments corresponding to the reservation are reversed in operation 2740c- 

If the member submits a payment, then the payment is collected in 
operation 2754c. After the payment is collected or if the delinquency policy 
does not fail, then the validation rules are processed in operation 2752c. In 

10 operation 2756c, the reservation is booked. In operation 2758c, the agent 
gathers additional member information. In operation 2760c, actions are 
generated- And, in operation 2762c, usage rights for the member are updated. 
The member is then able to use the timeshare reserved. 

Referring to Figure 27d and 27e, if the member seeks to make a points 

15 reservation, then the member may enter a request in operation 2702e- In 

operation 2704e, the member may request a single date for the reservation or a 
range of dates for the reservation. If a single date is requested, then 
availability is scanned in operation 2706e and the result is displayed in 
operation 2708e. If the request is available, then the availability is held in 

20 operation 2710e. If a date range is requested in operation 2704e, then the 

range is scanned for availability in operation 2716e. If the request is available, 
then a list of options are presented in operation 2720e and the user may select 
an option is operation 2722e. The option selected is held in operation 2710e. 
If either a date is not available, a date range is not available, or the member 

25 does not select an option, then the member may make a new request in 
operation 2702e. 

After a request is held in operation 2710e, then the Tool determines if 
the member passed the rules in operation 2712e. If not, then the agent may^ 
override the rules in operation 2714e or end the reservation process in 
30 operation 2715e. If the member passes the rules, then the Tool verifies that 
the member has enough points for the hold performed in operation 2710e. If 
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the member does not have enough points, then the member may borrow points 
in operation 2730e or rent points in operation 2732e. If the member does not 
borrow or rent points, then the inventory held is released and the member may 
make an additional request in operation 2724e or end the reservation process. 
5 If the member has enough points, borrows points, or rents points, then 

the Tool determines if there is a transaction fee in operation 2738e. If there is 
a transaction fee, then the agent may override the fee is operation 2740e. If 
the fee is not overridden, then the member pays the fee. In operation 2744e, 
the Tool determines if there are any payments to process. If so, the payments 
10 are processed in operation 2746e. In operation 2748e, the Tool determines if 
the customer resolved any outstanding financial obligations. If not, then the 
availability is released and any payments are reversed. 

If the members has resolved any outstanding financial obligations in 
operation 2748e or there are any payments to process, then the Tool processes 
15 the delinquency policy in operation 2752e. If the delinquency policy fails in 
operation 2754e, the agent may request payment from the member in operation 
2756e. If the payment is not collected, then the delinquency policy fails in 
operation 2758e and the availability is released in operation 2750e. If the 
payment is collected or the delinquency policy does not fail, then the validation 
20 rules are processed in operation 2760e. 

In operation 2764e, the members points account is decremented and the 
reservation is booked in operation 2766e. In operation 2768e, the agent 
gathers additional information. In operation 2770e, actions are generated. In 
operation 2772e, the members usage rights are updated based on the 
25 reservation. After operation 2772e, the reservation operations for a points 
based reservation are complete. 
Points Rate Definition 

The Tool includes points rate definition which allows the Tool to define 
nightly point rates for use in the reservation process. Members with a points 
30 usage right and a points reservation policy associated with the usage right can 
request a reservation for a piece of inventory. The arrival date and length of 
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stay will determine the availability of the inventory and then the point rate 
associated with the reservation. The rates are defined for a hotel cluster and 
weekend night combination. 

A presently preferred embodiment of the present invention and many of 
) its improvements have been described with a degree of particularity. It should 
be understood that this description has been made by way of example, and that 
the invention is defined by the scope of the following claims. 
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Claims 

We claim: 1 . A computer based method used in timeshare development and 
management for defining a timeshare product, comprising the operations of: 
defining a usage type based on the arrangement of a set of usage type 
variables; and 

defining at least one usage right associated with the usage type, the at 
5 least one usage right based on the arrangement of a set of usage right 
variables; 

whereby the characteristics of the product are a fiinction of the usage 
type and the associated at least one usage right. 

2. The method according to claim 1 wherein the usage type includes 
10 a space dimension component and a time dimension component. 

3, The method according to claim 1 wherein the usage type includes 
a point -based usage type. 

4- The method according to claim 1 wherein the usage type includes 
a space dimension component, a time dimension component, and a points- 
15 based component. 

5. The method according to claim 1 wherein the set of usage type 
variables include a sales time unit variable, a sales time unit count variable, a 
sales increment variable, a sales points variable, a pricing unit allocation 
variable, a pricing time allocation variable, a contract unit allocation variable, 

20 and a contract time allocation variable. 

6. The method according to claim 2 wherein the space dimension 
component includes one of a fixed space dimension component and a floating 
space dimension component. 

7. The method according to claim 2 wherein the time dimension 
25 component includes one of a fixed time dimension component, a floating time 

dimension component, and a fractional time dimension component. 

8. The method according to claim 1 wherein the usage type includes 
a whole ownership usage type and a pure points usage type. 
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9. The method according to claim 1 further including the operation 
of defining a time unit. 

10. The method according to claim 9 wherein the time unit is a 
function of a day. 

1 1 . The method according to claim 1 0 wherein the time unit includes 
a baseline factor, the baseline factor defining the time unit as an even multiple 
of a day. 

12. The method according to claim 10 wherein the time unit includes 
a baseline factor, the baseline factor segmenting the time unit into discrete 
portions of a day. 

13. The method according to claim 1 wherein the operation of 
defining at least one usage right includes the operations of defining a 
reservation start date and a reservation end date for each at least one usage 
right, the reservation start date and end date together defining a reservation 
window in which a reservation can be made for the product being defined, the 
reservation start date defining the first day of the reservation window that a 
reservation can be made and the reservation end date defining the last day of 
the reservation window that a reservation can be made. 

14. The method according to claim 1 wherein the operation of 
defining at least one usage right includes the operations of defining a usage 
start date and a usage end date for each at least one usage right, the usage 
start date and the usage end date together defining a usage window in which 
the product being defined may be used, the usage start date defining the first 
day of the usage window that the product may be used and the usage end date 
defining the last day of the usage window that the product may be used. 

15. The method according to claim 1 wherein the operation of 
defining at least one usage right fiirther includes the operation of defining an 
accommodation for each at least one usage right, wherein the accommodation 
includes unit, unit type and resort. 

16. The method according to claim 1 wherein the operation of 
defining at least one usage right includes the operation of defining a Boolean 
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operator, wherein the Boolean operator determines the interaction between 
each usage right defined. 

17. The method according to claim 1 wherein the operation of 
defining a usage right includes the operation of defining at least one policy 
associated to the usage right wherein the policies include rental and exchange. 

18. The method according to claim 1 further including the operation 
of adding a membership to the product wherein the membership includes 
additional usage rights. 

19. The method according to claim 1 further including the operation 
of defining a points package for the product, the points package including a 
points increment representing the number of points that the points package 
represents. 

20. A computer based method used in timeshare development and 
management for developing and managing timeshare inventory, comprising the 
operations of: 

defining at least one timeshare product, each product having space and 
time characteristics; 

defining at least one sales inve\itory, each sales inventory including a set 
of sales inventory entities available for association with the timeshare product, 

> the sales inventory entities defining a plurality of particular spaces; and 
linking at least one timeshare product with at least one sales inventory 

to create a product inventory, the product inventory including a set of product 
inventory entities available for sale as a timeshare interest, the product 
inventory entities including particular rights to space and time that can be used 

> by a purchaser of the timeshare interest. 

21. The method according to claim 20 wherein the operation of 
defining at least one sales inventory includes the operation of defining a resort, 
defining a unit type and defining a unit. 

22. The method according to claim 20 including the operations of 
) defining at least one hotel inventory, and mapping the at least one hotel 

inventory to the at least one sales inventory. 
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23. The method according to claim 22 wherein the operation of 
defining at least one hotel inventory includes the operations of defining a 
resort, defining a cluster, defining a room type and defining a room. 

24. The method according to claim 20 wherein the operation of 
5 linking at least one product to at least one sales inventory includes the 

operations of selecting the at least one product, defining a search criteria that 
describes a particular entity within the set of sales inventory entities, searching 
the at least one sales inventory according to the search criteria, and displaying 
any matches between the search criteria and the at least one sales inventory 
10 found in the search. 

25. The method according to claim 24 wherein the at least one 
product includes a non pure points product, and wherein the operation of 
linking the at least one product to the at least one sales inventory for the non 
pure points product includes the operations of defining a product calendar, 

15 defining a maintenance increment, initializing a pricing attribute, initializing a 
points attribute, initializing an inventory dates attribute, and initializing a 
business entities attribute. 

26. The method according to claim 24 wherein the at least one 
product including a pure points products, and wherein the operation of linking 

20 the at least one product to the at least one sales inventory for the pure points 
product includes defining a price for the pure points product, and initializing a 
business entities attribute. 

27. A computer based method used in timeshare development and 
management for developing and managing timeshare inventory, comprising: 

25 selling a timeshare interest, the timeshare interest including at least one 

usage right defining how the timeshare interest may be used; and 

resolving the at least one usage right to generate at least one resolved 

usage right wherein the at least one resolved usage right defines how the 

timeshare interest may be used at a particular time. 
30 28. A computer based method used in timeshare development and 

management for developing and managing timeshare inventory, comprising: 
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defining a timeshare product including at least one usage right; 
defining a sales inventory; 
defining a hotel inventory; 

linking the timeshare product to the sales inventory to define a product 
5 inventory including a set of product inventory entities available for sale, each 
of the product inventory entities including the at least one usage right; 
selling a product inventory entity; 

resolving the at least one usage right to generate at least one resolved 
usage right; and 

10 allowing a reservation to be made for the product inventory entity based 

on the at least one resolved usage right. 

29. The method according to claim 28 wherein the operation of 
selling a product inventory entity fiirther includes the operations of selecting a 
product inventory entity, defining a search criteria for the product inventory 

1 5 entity including a space dimension search criteria and a time dimension search 
criteria, searching for the product inventory entity matching the search criteria, 
and selecting a product inventory entity from a set of product inventory 
entities that match the search criteria. 

30. The method according to claim 28 wherein the operation of 

20 defining a sales inventory includes the operations of defining a resort, defining 
at least one unit type and defining at least one unit. 

3 1 . The method according to claim 28 wherein the operation of 
defining a hotel inventory includes the operations of defining a resort, defining 
at least one room type and defining a room. 

25 32. The method according to claim 28 wherein the operation of 

defining a product includes the operations of defining a time unit, and defining 
a usage type using the time unit wherein the at least one usage right is 
associated to the usage type. 

33. A software system for timeshare development and management 

30 comprising: 
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a usage type definition module including a set of definable usage type 
variable fields; 

a usage right definition module including a set of definable usage right 
variable fields; and 

5 a timeshare product definition module including a set of definable 

timeshare product variable fields; 

whereby the usage type module, the usage right module and the 
timeshare product definition module can be utilized together to define a 
timeshare product. 

0 34. The system according to claim 33 further comprising a time unit 

definition module. 

35. A computer program product embodied in a tangible media 
comprising: 

a set of program code to implement a usage type definition module 
5 wherein the usage type definition module includes a set of definable usage type 
variable fields; 

a set of program code to implement a usage right definition module 
wherein the usage right definition module includes a set of defmable usage 
right variable fields; 
0 a set of program code to implement a timeshare product definition 

module wherein the product definition module includes a set of definable 
timeshare product variable fields; and 

whereby the usage type module, the usage right module and the 
timeshare product definition module can be utilized together to define a 
:5 timeshare product. 

36. The computer program product of claim 35 wherein the tangible 
media comprises a magnetic disk. 

37. The computer program product of claim 35 wherein the tangible 
media comprises an optical disk. 

0 38. The computer program product of claim 35 wherein the tangible 

media comprises a propagating signal. 
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39. A system used in timeshare development and management for 
developing and managing timeshare inventory, comprising: 

a timeshare product definition module including a set of time unit 
definition fields, a set of usage type definition fields, and a set of usage right 
5 definition fields, the product definition module operative to create a timeshare 
product; 

a sales inventory definition module including a set of resort definition 
fields, a set of unit type definition fields and a set of unit definition fields, the 
sales inventory module operative to create a sales inventory that includes a set 
10 of sales inventory entities; and 

a product inventory definition module including a product field, a set of 
sales inventory entity fields and a linking module, the linking module operative 
to link the timeshare product with the sales inventory entity to create a product 
inventory that includes a set of product inventory entities that are available for 
15 sale as a timeshare interest. 
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